VTY access-list on 2951 router

[siddhartham]

I am having issues with the VTY access-list on the 2951 router,below is the config. When I apply that config I can't access the router from 10.X.X.150 and also don't  see the hit counts under sh ip access-list command. 

sh ip access-list

Extended IP access list VTY_ACCESS

    10 permit tcp host 10.X.X.150 any eq 22 log

    20 permit tcp host 10.X.Y.150 any eq 22 log

    50 deny ip any any log

line vty 0 4

exec-timeout 15 0

access-class VTY_ACCESS in vrf-also ( tried without vrf-also, but didn't work)

authorization exec vty

accounting commands 0 vty

accounting commands 1 vty

accounting commands 15 vty

accounting exec vty

login authentication vty

transport input ssh

IOS version--- c2951-universalk9-mz.SPA.152-2.T.bin

Siddhartha       

[Richard Burts · Accepted solution]

Siddhartha

It gets very tricky trying to use extended access lists in the access-class on the vty. I suggest that you re-write the access list as a standard access list. I believe that you will find that this works much better.

And you do not need to test for SSH in the access list. Since the vty has specified that SSH is the only input transport protocol then SSH will be the only thing that gets through, so trying to check it in the access list is redundant.

Give it a try as a standard access list and let us know how it works.

HTH

Rick

[siddhartham]

Thanks Rick, I used the Standard access-list and it worked just fine. Do you know why the extended one didn't work? In the extended access-list, I even tried IP any any but it didn't work

Standard IP access list 90

    10 permit 10.X.X.150 (6 matches)

    30 permit 10.Z.Z.0, wildcard bits 0.0.0.255 (2 matches)

sh ip access-list

Extended IP access list VTY_ACCESS

    10 permit tcp host 10.X.X.150 any eq 22 log

    20 permit tcp host 10.X.Y.150 any eq 22 log

Siddhartha

[Richard Burts]

Siddhartha

I am not sure about why. From my testing of this I know that IOS has manipulated the connection request for remote connection before it gets to the examination of access-class. I know that the destination address is no longer part of the data by the time access-class examines it. My guess is that IOS has also stripped out the protocol which would cause your access list to not match the request.

Did I understand correctly that you have tried permit ip any any in the access list and it still did not work? I thought that in my testing that this did work and so am surprised if it did not work for you.

HTH

Rick

[Peter Paluch]

Hello Rick,

I am also aware of the difficulties related to using extended ACLs in access-class constructs on VTYs. Right now, I have created an ACL 100 with a single "permit ip any any log" entry, and these are the log messages on the router where I have used this ACL in an access-class statement:

*Mar  1 00:01:16.507: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 10.0.0.1(32399) -> 0.0.0.0(23), 1 packet

*Mar  1 00:01:33.659: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 10.0.0.1(19935) -> 0.0.0.0(23), 1 packet

*Mar  1 00:02:04.367: %SSH-5-ENABLED: SSH 1.99 has been enabled

*Mar  1 00:02:25.087: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 10.0.0.1(15360) -> 0.0.0.0(22), 1 packet

*Mar  1 00:02:36.599: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 10.0.0.1(25322) -> 0.0.0.0(22), 1 packet

The first two lines correspond to me telnetting into this router from the source IP address 10.0.0.1. The last two lines correspond to accessing this router via SSH from the same source IP. As can be seen here, the destination IP address as supplied to the ACL was 0.0.0.0, not the IP address of this router to which I telnetted/SSHed (which happens to be 10.0.0.2).

I would speculate that the IOS zeroes out the destination address when passing data to the ACL because otherwise, it would be quite difficult to build an ACL that would take into account all IP addresses this router has, even considering the fact that the IP addresses may change over time. This way, regardless of what IP address has been used to remotely access this router, once the ACL in the access-class is consulted, it is already clear that this traffic is intended for us so there is no point in being picky about the destination IP address anymore.

My two (euro)cents...

Best regards,

Peter

[Richard Burts]

Peter

Thanks for your two (euro) cents - appreciated and insightful as always.

Your output shows clearly what I had described about the IOS removing the destination address before the data is matched against the access list in access-class. And that makes a lot of sense. One of the big advantages of using access-class is that it applies to any request for remote access, and it does not matter what interface or what address was the destination in making the request.

I had also wondered if IOS removes the protocol from the request data. Since IOS checks the protocol agains the transport input specification before it gets to the access list and it only gets to the access list if the protocol of the request matches the transport input protocol perhaps IOS does not consider the protocol in the check of the access list. But your output seems to show that IOS does still recognize that it was telnet or SSH. So perhaps putting the protocol in the access list is not an issue.

HTH

Rick

[siddhartham]

Thanks Peter and Rick for your explanation.

Rick,

Did I  understand correctly that you have tried permit ip any any in the access  list and it still did not work? I thought that in my testing that this  did work and so am surprised if it did not work for you.

Just to make sure I tested again with IP any any but it didn't work and no hit count for the access-list entries.

Peter,

Which debug statement did you use to examine the access-list traffic. I tried using debug ip packet detail 103 (access-list number) but it didn't give any uefull info.

Siddhartha

[cadet alain]

Hi,

Peter didn't use any debug but just the log keyword at the end of the ACL used for the access-class stement.

Regards.

Alain.

Don't forget to rate helpful posts.

[Richard Burts]

Siddhartha

Could you post your config so that we can see what does not work? I wonder if it might be the difference between using a named access list vs using a numbered access list? Peter was using access list 100 and it worked. Your postings show use of named access list. What happens if you configure it with a numbered access list with permit ip any any?

HTH

Rick

[Peter Paluch]

Hi Rick,

Thank you for your kind words!

Regarding the use of a named ACL instead of a numbered ACL - that got my attention. However, I've tried that right now and it does not seem to make a difference after all:

*Mar  1 01:25:42.715: %SEC-6-IPACCESSLOGP: list VTY permitted tcp 10.0.0.1(57661) -> 0.0.0.0(23), 1 packet

*Mar  1 01:26:03.183: %SEC-6-IPACCESSLOGP: list VTY permitted tcp 10.0.0.1(30188) -> 0.0.0.0(22), 1 packet

Here, the ACL named "VTY" was placed on line vty 0 15, and it still seems to report the same input values to the ACL as with number ACLs.

I wonder if this behavior is dependent on IOS version. I am running 2691 IOS image 12.4(15)T13.

Best regards,

Peter

[Richard Burts]

Peter

Thanks for the additional testing on possible differences between named and numbered access lists. +5 for that clarification that they both work the same.

It leaves me puzzled why the access list did not work for Siddhartha

HTH

Rick

[siddhartham]

It may be the IOS related, becaue I used same named access-list on other 2951s with different IOS and it woked fine.

Siddhartha

[Peter Paluch]

Hello Siddhartha,

Surely sounds like differences in IOS versions. Nevertheless, I really suggest paying a close attention to the output generated by the log keyword in your ACLs - your original ACL has this keyword in each of its statements so that should give you a hint which connection was handled by which ACL entry and possibly why. Make sure that the logging messages are recorded either using the logging buffered configuration or by logging all messages to a Syslog server.

Best regards,

Peter