IOS Firewall ICMP broadcast packet - no state created?

[andrew.butterworth]

I have the IOS firewall enabled on a C891F router - IP inspect.  Its all working, however I have hit an issue with a specific destination IPv4 address that bypasses the inspection and doesn't create the state for the returning packets.

I have masked the 1st three octets for my source and destination in the sample output below, however the behaviour is the same for any destination address that ends 'x.x.x.255'.

1880338: Jun 29 08:25:03.831 GMT: FIREWALL: ICMP Echo pkt 149.1.1.1 => 195.1.1.255
1880339: Jun 29 08:25:03.831 GMT: FIREWALL ICMP broadcast packet (149.1.1.1) => (195.1.1.255)
1880340: Jun 29 08:25:03.831 GMT: FIREWALL* sis 11018CC L4 inspect result: unexpected 235077632 PASS packet 106D63C0 (149.1.1.1:8) (195.1.1.255:0) bytes 32 ErrStr = No Error
1880341: Jun 29 08:25:03.843 GMT: FIREWALL: ICMP Unreachable pkt 149.1.1.1 => 195.1.1.255

My source IPv4 address is 149.1.1.1 and the destination is 195.1.1.255.  The 195.1.1.255 is from a /30 block we are using to do some testing so it is split into 4 x /32 host addresses (195.1.1.252/32, 195.1.1.253/32,195.1.1.254/32 & 195.1.1.255/32) that are announced within our AS.  The other four addresses don't cause the issue so its obviously due to the .255.

The C891F is running IOS 15.6(1)T3 and I can't go beyond this as all later releases contain a bug with SIP RTP that has never been fixed.  With every new IOS release I test, see the bug when making a SIP call and then revert back to 15.6(1)T3 as the issue doesn't occur with this release (there is a traceback and a disruption to the RTP stream every 30-seconds).

Any takers?

Andy

[Giuseppe Larosa]

Hello @andrew.butterworth ,

what if you add a static route /32 for x.x.x.255/32 pointing to the exit WAN interface ?

It is an attempt to help the router to understand it is a unicast address the destination address in ICMP packet.

I apologize if you have alredy tried this trick.

Hope to help

Giuseppe

[andrew.butterworth]

Already tried that and get the same results Giuseppe.  I suspect its a bug as its quite old IOS.  I'll update the IOS to that latest and test it again when I get chance.  Its not a huge inconvenience now that I know what the issue is.

I've been working from home and my IPv4 address is dynamic so rebooting and getting a new IPv4 address assigned to the router means I need to update a few ACLs or various devices.  Not a big deal but something I need to schedule in....

Andy