2900 router ignoring layer 3 destination IP and processing packet internally - bug or normal?

tonypearce1 · ‎12-20-2018

I have a 2900 router which is processing SIP packets which are destined for unknown IP addresses. Included in these unknown addresses are addresses which appear on the LAN side of the router and also the subnet ID of the router interface (not the ip assigned to the interface but the derived subnet ID). To put it simply, the router is ignoring the layer 3 destination IP address and passing the packet up the stack to the SIP process running there.

Further explanation : info:

We have this diagram:

gi0/0 - WAN facing with IP 132.0.0.1/30

|
2921 router - - - gi0/2 - LAN facing (routed WAN subnet) with IP 203.0.0.177/28

|

gi0/1 - LAN interface with IP 192.168.1.1/24

gi0/0 and gi0/2 are VRF 2
These two interfaces have the only purpose to connect the ISP to the outside of a firewall. VRF Lite is used to separate these two intefaces from the global route table on the router.

gi0/1 is the LAN port / CUBE port and runs SIP CUBE functionality.

The issue detail:

We have a firewall which has IP address 203.0.0.178. This firewall is not this router. This router has the purpose of routing traffic to / from the ISP (connected on port gi0/0) and our firewall (connected on port gi0/2). In addition and separately, we have CUBE / SIP function on gi0/1.

The issue seen here is that a random internet source is able to target IP address 203.0.0.176 (and other IP addresses not configured on the router) by sending a SIP invite to 203.0.0.176:5060. The router sends this packet to the SIP process and processes the packet normally at layer 7.

The issue is that the router is not checking the layer 3 destination address, and is therefore not dropping the packet due to invalid layer 3 destination address.

I raised this with Cisco TAC and the TAC response is that "this is normal operation".

My ACL denies any source to the router IP's, for example "deny any host 203.0.0.177". Because I have a firewall on 203.0.0.178 and there are more addresses in the /28 range such as .179 / .180 ... I also have an ACL line to permit: "permit any 203.0.0.176 0.0.0.15. So in this case, the packet with destination IP of 203.0.0.176 or another example: 203.0.0.192 are making it past ACL validation.
My expectation:
The packet with destination .176 is a subnet ID and so it's not possible to configure this address on the router due to this. The expectation with this packet is that the router should drop the packet - the router does not have this address configured on any interface (no secondary address etc)
The packet with destination .191 would normally appear on gi0/2 broadcast domain. So the router does send an ARP request. But this IP is not in use and so ARP does not get a reply. It's my expectation that the router cannot forward the packet and so should drop the packet. However instead, the router sends this packet to the SIP process and processes the SIP INVITE.

Mitigation:
Partly the reason for the issue is due to no SIP binding. It's easy to configre sip binding to gi0/1 like this:
voice service voip
sip
bind control source-interface GigabitEthernet0/1
bind media source-interface GigabitEthernet0/1

TAC
I reported the issue to TAC but they advise me that this is normal experience without binding. Without binding the router "listens on any ip address" even if the dest. ip address is a subnet ID / not configured on the router / some other device.

I dont feel this is correct because it breaks the OSI model. Layer 3 of the model should evaluate the IP addresses. This is not happening here. The packet is being sent passed layer 3 processing (it's not processing layer 3).

Tested code version: 15.4(3)M4

What are your thoughts on this? Normal or bug?

Georg Pauwen · ‎12-21-2018

Hello,

I have read through your post, and I remember something from the older IOS versions, but I am not sure if this is even relevant or applies to your specific issue.

It used to be that, by default, the "voice service voip" sub-command 'ip address trusted authenticate' was enabled, causing IP address authentication on incoming H.323 or SIP trunk calls for toll fraud prevention.
You could use the "show ip address trusted list" command to display a list of valid IP addresses for incoming H.323 or SIP trunk calls, and add additional valid IP addresses via:
voice service voip
ip address trusted list
ipv4 <ipv4-address> [<ipv4 network-mask>]

tonypearce1 · ‎12-23-2018

Your comment is helpful for use in a mitigation step against this router ignoring layer 3 issue

Peter Paluch · ‎12-24-2018

Hello Tony,

In addition to Georg's suggestion, I would like to point your awareness to another fact.

You have mentioned that SIP invites sent to 203.0.0.176:5060 will get processed on this router although the router itself has the IP address 203.0.0.177. To many operating systems including Cisco IOS, the IP address of the network also acts as a broadcast address itself: The router will listen on the address of the network, and process received packets if they are targeted to the network's address. In other words, your router listens on 203.0.0.176 and 203.0.0.191 in addition to its own 203.0.0.177. Therefore, it would be expected for the router to process packets destined to either one of these three IP addresses because .177 is the router's own address, and the .176 and .191 are treated as directed broadcasts.

However, it would be very strange if the router also responded to SIP invites sent to, say, 203.0.0.190 (assuming this address is unused) - does this happen, too?

A small correction to what you have stated: "The packet with destination .191 would normally appear on gi0/2 broadcast domain. So the router does send an ARP request." In fact, the router will not send an ARP request for this IP address. Based on its configuration, it knows right away that the IP address is a directed broadcast for its directly connected network 203.0.0.176/28, and such packets would be automatically encapsulated into frames with the ffff.ffff.ffff destination MAC. No ARP is needed for this. If a packet for .191 is received from outside, your router will certainly process it because it also listens on .191, however, it will not route it into the network on your Gi0/2 unless you configure the ip directed-broadcast on that interface since forwarding of directed broadcasts is disabled by default for obvious security purposes.

Looking forward to hearing from you!

Best regards,
Peter

tonypearce1 · ‎12-26-2018

Hi Peter,

Firstly - I was somehow confused with the .191 thinking it was a host address. Not sure how I made that error (probaby confused with .181).

I was completely unaware of the expectation that you mentioned. I went and checked my captures and logs and confirmed that I only see the router actioning packets to .176 and .191 which are the network and broadcast addresses of the router.

With the info you detailed I'll do some more research on this but looks like I'll need to file this one into the "remember always" list and block internet > router subnet/broadcast ID's in the future!

Thanks!