Strange ACL behaviour

[stancu8]

Hi,

I faced strange problem after IOS upgrade.

Namely, I have access-lists on line vty which permit only my management stations for remote access using ssh.

I have ACL like that:

ip access-list extended ACCESS

permit tcp host 10.x.x.1 host <router_ip> eq 22 log-input

permit tcp host 10.x.x.2 host <router_ip> eq 22 log-input

permit tcp host 10.x.x.3 host <router_ip> eq 22 log-input

deny ip any any log-input

After upgrade to higher version of IOS in SYSLOG I can see that acl ACCESS denied traffic from 10.x.x.1 host to strange IP address like:

31.x.x.x

32.x.x.x

33.x.x.x

61.x.x.x

62.x.x.x

This address is different every single ssh session.

NAT is not configured.

When I do show access-list ACCESS i can see that first match is in correct acl entry but second is on deny any any.

I tested this IOS: 15.7(3)M6 and 15.6(3)M8. Router CISCO 2911/K9.

Before upgrade with IOS 15.0.... there were no problem.

Anyone have any idea?

I'll be grateful for any help.

Regards.

[Richard Burts]

It is not clear in the post whether this access list is applied using access-class on the vty or is applied some other way. Can you provide clarification?

In my experience using extended access lists with access-class does not work correctly unless the destination address is specified as "any". So it makes me wonder if the access list is applied using something other than access-class. Perhaps seeing the appropriate parts of the configuration might be helpful.

[stancu8]

ACL is applied of line vty by access-class. I mentioned it at the beggining :) It is extended access-list

I cannot provide exact config.

What kind of problems you had with extended acls?

Before upgrade I had acl entry like below and it worked correctly: 

permit tcp host 10.x.x.1 host 0.0.0.0 eq 22 log-input

After upgrade my connection was refused.

With any I don't have any trouble.

Regards

[Richard Burts]

The original post specified that you had an access list but did not specify how it was applied. Thank you for confirming that it is applied using access-class. That makes a big difference in how the acl works. And yes it is true that when you specify the destination as any it will work and when you specify any particular destination address and mask it does not work when using access-class . The complete explanation is complex but here is the simple explanation. When you apply the acl using access-group on an interface it is specific to that interface and both the source address and destination address are significant so the acl evaluates the IP packet as received and will see the destination address in detail. But when you apply the acl using access-class it is not specific to an interface or to a particular destination. It is intended to evaluate any attempt at remote access where the IOS device is the target. So as the request gets to the point where the remote access request is evaluated the destination address is ignored and the acl applied with access-class will evaluate the source address but not the destination address. As far as I know this behavior is the same on all versions of IOS.

[stancu8]

---

@Richard Burts wrote:

As far as I know this behavior is the same on all versions of IOS.

---

Not exactly.

On ISR4331, IOS 16.12.03 I configured Ext ACL like that:

permit tcp host 10.x.x.1 host <router_tunnel_ip> eq 22 log-input

and it works fine

On ISR4331, IOS 16.03.04 I configured Ext ACL like that:

permit tcp host 10.x.x.1 host 0.0.0.0 eq 22 log-input

and it worked until upgrade to OS 16.12.03, mentioned above.

On 2911/K9 after upgrade to 15.7(3)M6 both mentioned above solutions are not working.

Before upgrade, on IOS 15.0(4)... permit tcp host 10.x.x.1 host 0.0.0.0 eq 22 log-input worked fine.

But, I accept your words and knowledge. I didn't knew that it is preferred to use standard acl on line vty.

Thank you for your time and help :)

[Richard Burts]

You are welcome. It is interesting to know that there are some versions of code where an extended acl used in access-class does work. But they are exceptions to the expected behavior. In general it is preferred to use standard acl with access-class.