05-17-2021 03:59 AM - edited 05-17-2021 07:25 AM
Hi,
I have got an ASR920 with a loopback address of 192.168.0.27 that we use for management. I want to regulate SSH access to limit it only to the network 192.168.17.0/24, so I created this ACL:
permit tcp 192.168.17.0 0.0.0.255 host 192.168.0.27 eq 22
I configured this ACL in ingress under the VTY 0-15 lines.
The computer I am using to ssh on the router has an ip that falls within the 192.168.17.0/24 network but with the ACL configured that way, I cannot connect to the device (remote host refused the connection).
I tried to remove the ACL from the VTY to confirm the ACL was the issue and I could SSH into the router just fine. I also issued the "sh users" to check what IP I was logged into the router with and it reported a 192.168.17.48 address, which falls under the allowed network.
I also tried to change the ACL to:
permit tcp any host 192.168.0.27 eq 22
again, I configured that on the VTY lines on the router. At this point my IP should be pretty much irrelevant and as long as I start a SSH session towards "192.168.0.27" I should be able to establish it but, the router refuses the connection.
Could anyone help me out figuring what I am doing wrong? Thanks
Solved! Go to Solution.
05-17-2021 07:41 AM
Hi Thomas,
Try using a standard ACL instead.
ip access-list standard 1
permit 192.168.17.0 0.0.0.255
!
line vty 0 5
access-class 1 in
Regards,
05-17-2021 07:41 AM
Hi Thomas,
Try using a standard ACL instead.
ip access-list standard 1
permit 192.168.17.0 0.0.0.255
!
line vty 0 5
access-class 1 in
Regards,
05-17-2021 08:07 AM
@Harold Ritter is exactly right. There is a significant (but not obvious) difference between standard access list and extended access list when applied to line vty. For an interface we apply the access list using access-group and for this the extended access list will check both the specified source and the specified destination. For vty we apply the access list using access-class and the behavior is quite different. I believe that the underlying logic is that access-class is examining traffic for which the device is the destination. It does not matter which interface address was used as the destination, just that the device was the destination. So the logic in access-class does not check the destination address - as you discovered. If you want to use an extended access list then you need to specify the destination as "any" and it really is better to use standard access list rather than extended.
05-17-2021 09:57 PM
Hi Harold, hi Rick
Thank you very much for the suggestion and the explanation respectively. Doing as you said, allowed the ACL to work as I was expecting. Thanks again
05-17-2021 10:21 PM
You are welcome. I am glad that this discussion has been helpful. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.
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