Restrict SSH and Telent to single SVI

[DarrenB_UK]

Hi,

Consider a L3 switch with multiple SVIs:

Interface VLAN 10 - 10.0.10.254/24

Interface VLAN 20 - 10.0.20.254/24

Interface VLAN 30 - 10.0.30.254/24

Interface VLAN 7 - 10.0.7.254/24

Obviously all SVI IPs can be used to manage the switch.  I want to be able to restrict access to only 10.0.7.254 rather than expose ALL SVI IPs as management IPs.

I created a quick access list "permit ip any host 10.0.7.254" and applied it under the line vty config.

This resulted in NO SSH/Telnet access to the switch rather than the desired 10.0.7.254 only!

Any ideas guys?

Many thanks

[Richard Burts · Accepted solution]

You are attempting to use an extended access list and that is problematic when you use it with access class under the vty. You will not achieve your objectives if you try to do it with access-class under the vty. To achieve your objective you will need to apply an access list inbound on each of the layer 3 interfaces which will permit telnet and ssh to the desired address and will deny telnet and ssh to each of the other interfaces. I recognize that this will be tedious and not an attractive alternative, but it is the one that could work.

HTH

Rick

[DarrenB_UK]

I suspected that inbound ACLs would be one way of achieving this, but as you say, tedious!

i read that extended ACLs are supported on VTY lines though several sites allude to issues.

Shame really that what seemed like a logical application of an access class ACL didn't achieve the desired result :(

[Richard Burts]

Note that I did not say that extended access lists are not supported under the vty. They are supported for vty but they do not operate in the way that you are expecting.

I am not sure how familiar you are with BGP. But in configuring BGP you can use an extended access list to filter route advertisements. When you do this the second address is not specifying a destination address (as we are used to thinking) but is specifying the mask used for the route in the advertisement. I see this as another example of ways that an extended access list can be used but does not operate in the traditional way. Extended access list under vty is a sort of similar issue.

HTH

Rick

[Alexander Cousins]

Hi Darren

What you are trying to achieve cannot be achieved in that way. You could apply an access list to all of the SVI blocking ssh but that not really clean either. 

I have achieved the above on a router by enabling control plane-policing and them permitting the packets to the required IP address through an access list reference in a class map. 

The configuration is shown below.

ip access-list extended SSH-MGMT

 permit tcp any host 10.0.7.254 eq 22

class-map match-all SSH-MGMT

 match access-group name SSH-MGMT

ip access-list extended SSH-NON-MGMT

 permit tcp any any eq 22

class-map match-any SSH-NON-MGMT

 match access-group name SSH-NON-MGMT

policy-map SSH_PM

 class SSH-MGMT

 class SSH-NON-MGMT

  drop

 class class-default

control-plane host

 service-policy input SSH_PM

___________________________________

Router#sh policy-map control-plane all 

 Control Plane Host 

  Service-policy input: SSH_PM

    Class-map: SSH-MGMT (match-all)
      1487 packets, 120959 bytes
      5 minute offered rate 0 bps
      Match: access-group name SSH-MGMT

    Class-map: SSH-NON-MGMT (match-any)
      9 packets, 670 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name SSH-NON-MGMT
        9 packets, 670 bytes
        5 minute rate 0 bps
      drop

    Class-map: class-default (match-any)
      128 packets, 35832 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 

If this works for you please remember to rate the support and mark as solved.

Lex

[Alexander Cousins]

Just spotted this may not work on your switch as control-plane functionality can be fairly limited.

[DarrenB_UK]

Thank you for your input also.

Seems as though multiple inbound ACLs are the way...

[Mitesh Manwatkar]

Hi,

Just want to understand the importance of class class-default coomand in this case.

Regards,

Mitesh Manwatkar.

[Alexander Cousins]

The class-default command is there as an additional permit line. Since we are not looking to restrict any other management traffic. As it stands it will permit other management traffic like NTP and SNMP. 

Its probably best to be more specific and move these up to the permit line and block everything else but since this looks like a production node I put the safest not securest default in. 

HTH

[Mitesh Manwatkar]

We have Cisco 6509-E.....I dont see host argument after Control Plane command...does this work on Routers only?

PFA Below