05-09-2014 11:31 AM - edited 03-07-2019 07:24 PM
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
Solved! Go to Solution.
05-09-2014 12:40 PM
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
05-09-2014 12:40 PM
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
05-09-2014 02:38 PM
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 :(
05-10-2014 02:49 PM
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
05-09-2014 01:08 PM
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
05-09-2014 01:21 PM
Just spotted this may not work on your switch as control-plane functionality can be fairly limited.
05-09-2014 02:40 PM
Thank you for your input also.
Seems as though multiple inbound ACLs are the way...
05-12-2014 12:32 AM
Hi,
Just want to understand the importance of class class-default coomand in this case.
Regards,
Mitesh Manwatkar.
05-12-2014 01:17 AM
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
05-12-2014 09:49 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide