Hi, I try to filter ssh connections to our routers, to permit the access only to specific router IP adresses and tried the following example configuration:
access-list 111 permit ip any 10.255.255.0 0.0.0.255 log
access-list 111 deny ip any any log
line vty 0 3
access-class 111 in
transport input ssh
I hoped, unsing this ACL configuration, the access to the routers vty line could be filtered to an IP-address inside the 10.255.255.0/24 range only, independently on the source address. But this configuration does not work. The vty access-class policy seems not to be able to match on any destination IP:
An SSH connect, sourced from a neighboring router by: "ssh -vrf mgmt 10.255.255.3" is refused, because the connect matches always the final deny any rule and leads to the following syslog message on the target router:
Dec 22 15:29:06.233 UTC: %SEC-6-IPACCESSLOGP: list 111 denied tcp 10.255.255.2(65277) -> 0.0.0.0(22), 1 packet
Even the access-class out (with reversed ACL) command does not work, because this seems to match on outgoing connections only.
The background is, that we use a specific VRF for management purposes, and the permitted clients are already filtered by a firewall policy. But anyway, any client on any subnet on any other VRF ist able to connect to the router IPs inside their VRFs. Therefore the plan is, to restrict any access, to any router IP on the router, except those IPs, that are part of the management VRF.
Is there a way to implement such a policy, without implementing ACLs on every router IP interface (because this would mean to implement an ACL on hundreds of SVIs)?
Thanks in advance. Hakan
Solved! Go to Solution.
I too have run into this problem sometime ago, I found that the access-class policy seemed only to work with standard ACL's and source addresses.
From your experience it would seem that is still the case.
Can you filter only on your management source address range?
It is not true that access-class works only with standard access lists. I would suggest that it works best with standard access list. But it does work with extended access list when the extended access list is correctly configured. I have configured access-class using extended access lists and it does work. What you need to be aware of is that access-class does not differentiate the destination address (only the source address). So a correctly configured extended access list for access-class with have permit any for the destination.
If the original poster wants to restrict SSH access to a particular destination address then access-class is not the correct approach. To accomplish this you would need an access-group on each router interface with a permit tcp <whatever_source> <router_address_allowed> eq 22 and then deny tcp <whatever_source> <each_other_router_IP> eq 22. Effectively you must permit the SSH to the router address that you want to work and then you must deny SSH to every other router address and you must do this on each interface.
Control Plane Protection is an excellent suggestion. It takes away the need to do filtering on every interface.
Thanks, the CoPP approach works perfectly. In my testconfiguration I used two class-map and two policy-map statements, the first one allows and polices the autorized SSH traffic (matched on the destination IP-address by an extended ACL) and the second one drops any else (the unwanted) SSH traffic. Tested on an Catalyst 6880X
Is this the recommended approach?
police 500000 conform-action transmit exceed-action drop violate-action drop
police 32000 conform-action drop exceed-action drop violate-action drop