Object-group entry in ACL breaks IOS firewall

Unanswered Question
Aug 6th, 2010

My goal is to be able to edit firewall exceptions "on the fly" and without having to hack an ACL. I have created a service object-group that contains exceptions to the firewall, however when I apply this object-group to the firewall ACL, it opens up the ACL entirely!

What am I doing wrong with this configuration? Thanks very much for any insight you can provide!

Cisco 871 running c870-advsecurityk9-mz.124-22.T.bin. Here are the configs:

ip access-list extended FIREWALL
permit object-group FIREWALL-EXCEPTIONS any any log
permit udp any eq bootps any eq bootpc
deny   ip any any

object-group service FIREWALL-EXCEPTIONS

description <<< specific ports allowed through the firewall >>>
tcp eq 443
tcp eq 25

tcp eq 80

interface FastEthernet4
ip dhcp client client-id FastEthernet4
ip address dhcp
ip access-group FIREWALL in
ip access-group WAN-EGRESS-FILTER out
no ip redirects
no ip unreachables
no ip proxy-arp
ip accounting output-packets
ip accounting access-violations
ip nat outside
ip inspect INSPECT-FIREWALL out
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
arp timeout 600

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jon Marshall Fri, 08/06/2010 - 02:01

ip access-list extended FIREWALL
permit object-group FIREWALL-EXCEPTIONS any any log
permit udp any eq bootps any eq bootpc
deny   ip any any

object-group service FIREWALL-EXCEPTIONS

description <<< specific ports allowed through the firewall >>>
tcp eq 443
tcp eq 25

tcp eq 80

I have only used object-groups on firewalls so i may be wrong but assuming these ports are ports you want to allow inbound from the outside of your router your acl doesn't look right. Shouldn't it be

permit tcp any any object-group FIREWALL EXCEPTIONS log


s1rm@pl3bar Fri, 08/06/2010 - 09:09

You're right Jon. The ACL should actually read "permit tcp any any object-group FIREWALL-EXCEPTIONS" but the device won't take the command when it's structured like that! It's really throwing me off!

Maybe I've encountered a bug in the IOS?

Here's the output when I attempt to issue that ACL:

871-Firewall(config-ext-nacl)#5 permit tcp any any ?
  ack          Match on the ACK bit
  eq           Match only packets on a given port number
  established  Match established connections
  fin          Match on the FIN bit
  fragments    Check non-initial fragments
  gt           Match only packets with a greater port number
  log          Log matches against this entry
  log-input    Log matches against this entry, including input interface
  lt           Match only packets with a lower port number
  match-all    Match if all specified flags are present
  match-any    Match if any specified flag is present
  neq          Match only packets not on a given port number
  option       Match packets with given IP Options value
  precedence   Match packets with given precedence value
  psh          Match on the PSH bit
  range        Match only packets in the range of port numbers
  reflect      Create reflexive access list entry
  rst          Match on the RST bit
  syn          Match on the SYN bit
  time-range   Specify a time-range
  tos          Match packets with given TOS value
  ttl          Match packets with given TTL value
  urg          Match on the URG bit

Jon Marshall Fri, 08/06/2010 - 09:51

Actually i've just found a doc which shows how to use them and surprisingly your original syntax was correct. Why it can't be standard like other acl usage i don't know

So is that acl allowing everything in ? What does the acl look like when you do a "sh ip access-list FIREWALL_EXCEPTIONS" ?


s1rm@pl3bar Fri, 08/06/2010 - 10:29

Extended IP access list FIREWALL
    5 permit object-group FIREWALL-EXCEPTIONS any any log (62 matches)
    500 deny ip any any (3457 matches)

Service object group FIREWALL-EXCEPTIONS
  tcp eq 61259
  tcp eq 25222

The object-group shows up in the FIREWALL ACL, but I think the ios is reading the entry as "permit ip any any" and disregarding the object-group TCP information altogether.

The only external tool that I currently have access to is the "Shields Up" scanner at grc.com (not the most ideal test, but it works for my purposes!)

When I have the firewall ACL in place with NO object-group entry then the firewall blocks everything as it should (GRC returns "Stealth" for every port).

When I place the object-group entry into the ACL (as shown above) GRC returns that all scanned ports are "Closed" and it also sees the ASA 5505 that I have in testing behind the router is running Web VPN (port 443 shows "Open"). In addition to all that, the ACL that blocks input into the VTY lines reports that it has blocked an attempt from the GRC scanning IP.

This is driving me up the wall!    The ACL syntax is correct. The only two explanations I can think of are 1) IOS bug or 2) The device was reporting "

%ALIGN-3-SPURIOUS: Spurious memory access made at..." errors earlier in the week. 

Maybe I need to reload and/or upgrade the IOS?

bwilloughby Tue, 11/02/2010 - 09:54

We are seeing the same behavior in c2821 routers.  Did you receive a reolution tothis problem?

permit TCP object group * works

permit UDP object-group * works

permit IP object group * does not work

permit object-group * any any does not work

s1rm@pl3bar Tue, 11/02/2010 - 10:02

No. I have not yet found a way to make this work. If you find a resolution please let us know!

mdeloach Thu, 05/19/2011 - 09:04

I hust ran into a similar situation, not involving a group of ports, but a

range of networks-

object-group network A


object-group network B


ip access-list extended firewall

permit tcp object-group B object-group A eq smtp

deny any any

Testing reveled that any IP could now connect to my mail server.

Pulling the permit line blocked traffic, so I thought maybe the

range was not proper/working and replaced it with-

object-group network B /24 /24 /24 /24

I re-added the rule to the access-list and found that once again any IP

could connect to my email server.  So now I do not use object-groups

to define the source.  Rules with object-groups as the target all worked,

This is on a ISR 2851 running 12.4.(24)T4


This Discussion