How to Restrict Cisco Switch Management Access by IP Address

Anyone on your LAN or WLAN can reach your Cisco switch’s login page if management access isn’t restricted by IP address. If you’re cautiously hoping to close that gap without locking yourself out, start by preparing a recovery path.

Fix #1: Prepare your trusted management address

The Cisco SG300-10 and other Cisco Small Business 300 Series switches are retired, but plenty remain in service. These steps cover their legacy web interface; Cisco Business and Catalyst 1200/1300 switches use the same access-control concept with different menu locations.

1. Choose the computer or admin subnet that should manage the switch.

A single address such as 192.168.1.233 offers tight control, but it can stop working when DHCP assigns your computer another address. Reserve that address in your router, use a static address, or permit a small admin subnet.

2. Confirm the switch’s management IP address and management VLAN.

3. Connect to the switch through HTTPS from the trusted computer.

A browser certificate warning is common when a switch uses a self-signed certificate. Confirm that the address belongs to your switch before continuing.

4. Keep a console connection available during setup.

A USB-to-serial console cable gives you a recovery route if the new profile blocks your browser and SSH sessions.

5. Back up the current configuration before changing access rules.

Don’t activate a deny rule until the matching permit rule exists. That detail prevents the most common lockout.

Fix #2: Create a permit rule on an SG300 switch

An SG300 management access profile controls which source addresses can use services such as HTTPS and SSH. Lower rule-priority numbers are evaluated first.

1. Sign in to the SG300 web interface through HTTPS.

2. Expand Security > Mgmt Access Method, then select Access Profiles.

3. Confirm that None or your existing profile appears beside Active Access Profile.

Don’t replace an active profile until you’ve reviewed its rules.

4. Select Add to create an access profile.

5. Enter a descriptive profile name, such as MGMT_ONLY.

6. Set Rule Priority to 1.

7. Set Management Method to the service you want to permit.

Choose HTTPS for browser management or SSH for command-line access. If this firmware requires separate rules for each service, create one permit rule for HTTPS and another for SSH. Choose All only when every enabled management service should be available from the trusted address.

8. Set Action to Permit.

9. Set the interface to All, unless management must enter through a specific interface.

10. Under Applies to Source IP Address, select User Defined and Version 4 for an IPv4 address.

11. Enter the trusted source address, such as 192.168.1.233.

12. Enter 255.255.255.255 as the mask to match that single host.

To permit the entire 192.168.1.0/24 subnet, enter 192.168.1.0 with 255.255.255.0. A subnet is less restrictive, but it’s less likely to strand you when an admin computer’s address changes.

13. Select Apply.

14. Open Profile Rules and confirm that the permit rule appears with priority 1.

So far, so good: the trusted address has permission, but other addresses aren’t blocked until you add the next rule.

Fix #3: Add the deny rule

The deny rule must come after every permit rule. Cisco stops evaluating the profile when it finds the first matching rule.

1. Select Add under Profile Rule Table.

2. Choose the same access-profile name you created earlier.

3. Set Rule Priority to a number below every permit rule in processing order.

If your only permit rule uses priority 1, give the deny rule priority 2. Remember that lower numbers run first.

4. Set Action to Deny.

5. Set the management method, interface, and source address fields to All.

6. Select Apply.

7. Review the complete rule table.

Every approved IP address or subnet must have a permit rule above the final deny rule. To allow another administrator, add another permit rule and move the deny rule to a higher priority number.

Fix #4: Activate, save, and test the profile

Activating the profile is the risky step. Keep your current session open while testing from a second browser window or SSH session.

1. Return to Security > Mgmt Access Method > Access Profiles.

2. Select your new profile beside Active Access Profile.

3. Select Apply.

4. Open a second HTTPS or SSH session from the permitted address.

You should still reach the switch and sign in normally.

5. Test from a different LAN or WLAN address.

The blocked computer shouldn’t reach the login page or establish an SSH connection.

6. Leave the original management session open until both tests produce the expected result.

7. Go to Administration > File Management > Copy/Save Configuration.

8. Copy the running configuration to the startup configuration.

The restriction should now survive a reboot.

If the allowed computer loses access, use the console connection to disable the active profile or correct its permit rule. Don’t save the failed configuration to startup until access works.

Fix #5: Restrict access on newer Cisco switches

Cisco Business and Catalyst 1200/1300 models place ACL and management settings in different locations depending on their firmware. Look for Access Management, Access Control, IPv4 ACL, or ACL Binding rather than assuming the SG300 path will match.

1. Sign in to the switch through HTTPS.

2. Open its access-management or IPv4 ACL settings.

3. Create a permit rule for the trusted admin address or subnet.

4. Restrict the rule to TCP port 443 for HTTPS and TCP port 22 for SSH when the interface supports protocol-specific rules.

5. Add a deny rule for other management sources.

6. Bind the ACL to the management function, management VLAN, or management interface offered by that model.

7. Apply the ACL inbound where management traffic enters the switch.

8. Save the running configuration to startup configuration.

9. Test from both an approved address and a blocked address.

Be careful when binding an ACL to a switched virtual interface, or SVI. An SVI rule can affect other traffic using that VLAN, so match only SSH, HTTPS, and any required SNMP traffic when the VLAN also carries user data.

Fix #6: Apply an IOS-style ACL from the CLI

Use this pattern only on Cisco switches whose command reference supports IOS or IOS-XE syntax. The SG300 CLI is similar in places but isn’t command-for-command identical, so verify its administration guide before entering these commands.

1. Open Windows Terminal or PowerShell.

2. Connect to the switch with the built-in SSH client:

ssh admin@192.168.10.2

3. Enter configuration mode.

4. Create an extended ACL that permits HTTPS and SSH from the trusted host:

configure terminal
ip access-list extended MGMT_ONLY
 permit tcp host 192.168.10.50 any eq 22
 permit tcp host 192.168.10.50 any eq 443
 deny ip any any
 exit

5. Apply the ACL to the supported management interface or SVI:

interface vlan 10
 ip access-group MGMT_ONLY in
 exit

Applying this example to an SVI blocks all other inbound IP traffic matched by the final deny rule. I’d skip this binding unless VLAN 10 is dedicated to management or you’ve written additional permit rules for required traffic.

6. For SSH-only restrictions on supported IOS or IOS-XE switches, apply the ACL to the VTY lines:

line vty 0 15
 access-class MGMT_ONLY in
 transport input ssh
 exit

7. Keep the current session open and test a second connection from the permitted address.

8. Save the configuration using the command documented for your switch.

Fix #7: Separate management traffic with a VLAN

A dedicated management VLAN reduces exposure before an ACL evaluates a connection. It’s the stronger design for a managed network switch that supports VLAN interfaces.

1. Create a dedicated management VLAN on the switch.

2. Assign the switch’s management IP address to that VLAN.

3. Permit routing to the management VLAN only from an admin subnet or jump box.

4. Block other internal VLANs from reaching SSH, HTTPS, and SNMP ports through your firewall or router.

5. Apply a management ACL on the switch as a second control.

6. Disable Telnet and plain HTTP.

7. Enable SSH and HTTPS only.

8. Use strong local credentials or RADIUS/TACACS+ authentication when the switch supports it.

This setup is working as expected when ordinary wired and wireless clients can’t reach the switch, while devices on the admin subnet can connect through HTTPS or SSH.

When access still doesn’t work

Confirm the management IP, VLAN, and permitted source address from the console. Check that HTTPS or SSH is enabled, then temporarily permit the admin subnet instead of one host to identify a DHCP-address mismatch. If connectivity returns only after removing the ACL, review its rule order, direction, masks, and port matches before activating it again.

Conclusion

Fix #2’s permit-first access profile is the solid choice for an SG300 still in service, provided you test before saving. For a new deployment, I recommend a Catalyst 1200/1300 switch with a dedicated management VLAN, HTTPS or SSH, and an ACL that permits only the admin subnet.