Thursday 19 April 2012

Cisco bug: object-group ACL fails after reboot

It seems that object-group definitions are ridiculously buggy in router ACL's on IOS 12.4(24)T2.  Here's a simple example from my Cisco 877 router config.

object-group network LANhosts
access-list 102 permit tcp any object-group LANhosts established
access-list 102 deny   ip any any log
As an aside, it's silly to use the established condition in an ingress filter: better to use ip inspect tcp on egress, in order to get proper stateful behaviour.  But that's not the point of this example.

The permit tcp rule, based on the object-group named LANhosts, works perfectly after you clear and re-define the ruleset interactively:-
no access-list 102
access-list 102 permit tcp any object-group LANhosts established
OK.  We test this ruleset and it works perfectly.  You can execute show ip access-lists 102 and view the number of packet matches for each rule in the ruleset, and everything is as expected.  

Please note the write command to save the running configuration as the startup configuration.  That means that if we issue the reload command (or we have a power outage) then everything should come back in the same state when the router reboot.

What actually happens after a reboot, is that the rule access-list 102 permit tcp any object-group LANhosts established never matches any packets. Every incoming TCP frame hits the final line access-list 102 deny ip any any log instead.  This breaks my network when the router is rebooted.  But if I clear and re-define access-list 102 (as shown above) then everything starts working again. Crazy!

There is a potential security issue here.  Some of my deny rules use object-group definitions, so presumably those deny rules don't work properly either.  Meaning that unwanted traffic is allowed past my ingres ACL after a reboot.

I'll just have to rewrite the ingres ACL ruleset without using any object-group definitions.   For example, this rule works perfectly even after a reboot:-
access-list 102 permit tcp any any established
Update: I've upgraded to a later version of IOS that fixes the problem.  After studying the Cisco website, it turns out that the bug was present in 12.4(24)T2, but was fixed a few minor revisions later.  I can't remember exactly when (and can't check now because the Cisco site never works properly without a support contract).

No comments:

Post a Comment

Spammers: please stop wasting my time. All comments are moderated before publication.