object-group network LANhostsAs 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.
range 217.169.18.162 217.169.18.190
...
access-list 102 permit tcp any object-group LANhosts established
...
access-list 102 deny ip any any log
The permit tcp rule, based on the object-group named LANhosts, works perfectly after you clear and re-define the ruleset interactively:-
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.no access-list 102access-list 102 permit tcp any object-group LANhosts established...write
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 establishedUpdate: 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.