Apparent packet bounce from Linksys BEFSR81 firewall/router. WWW.Smythies.com

The problem: With firmware version 2.51.4.006, it seems as though the Linksys BEFSR81 firewall/router will re-transmit a packet that it should ignore. The packet was not addressed to the BEFSR81 in the first place and it is none of it's business to do anything with it.

The network security risk: This could be a security hole if one were to have any sort of Machine Address Code (MAC address, sometimes also referred to as Media Access Code) based trust between their multiple (usually two) external IP addresses. If the packet were to be accepted based on the MAC a new TCP session connection would be started, but the return IP address is actually the hacker, not your trusted place.

The bigger problem with firmware version 2.51.4.006: Owners of the Linksys BEFSR81 hardware firewall/router (harware version 3.0 in my case) should not use this firmware and should be aware that it has multiple issues:

• The release notes indicate that the firmware fixes DHCP NAK issues. It does not.
• The firmware introduces issues with its own web based interface, including blank pages with errors. (If you have this problem, then power cycle (power off for 30 seconds, then power up) the BEFSR81 and you should be able to access the web interface once and if you do it fast enough.)
• The firmware introduces the packet bounce issue, which is the main subject of this web page, and could be a security issue.
• If you can find it, firmware version 2.51.1 is recommended. (Right click and select "save target as" to save the binary 2.51.1 code file to your computer)

Details:My network has two static IP addresses, one is the Linksys BEFSR81 and the other is an Ubuntu Linux server. At the ethernet layer, most packets Machine Address Code (MAC address) destined for the Ubuntu Linux server (smythies.com) are from my ISP gateway. However, and rarely, the MAC address shows that a packet has come from the BEFSR81 yet the source IP address is from somewhere else on internet. Investigation using tcpdump (on smythies.com at 209.121.28.192) to capture raw packet data and wireshark to analyze the data reveal that the packet seems to have been bounced (re-transmitted) by the BEFSR81.

Below are two wireshark screen captures of an example occurance of the problem. The key things to observe: The absolute sequence number (highlighted) is the same for both the original packet and what I am claiming is the re-transmitted packet; the TTL (time to live) has decremented by 1 for the re-transmitted packet; The time stamps show minimal delay between the original packet and the re-transmitted packet.
Note: 00:90:1A:A0:FD:73 is the ISP gateway; 00:22:B0:75:C2:BD is the Ubuntu server; 00:14:BF:BC:25:EE is the BEFSR81.

The original packet goes directly to the desired IP address destination:



The (I am claiming) re-transmitted packet. The original had also gone to the BEFSR81 at 209.121.21.186, which (I am claiming) re-transmitted it:



Other notes:
The BEFSR81 was hardware version 3.0 and running firmware version 2.51.4.006.
Since downgrading to firmware version 2.51.1, the packet bounce issue has not occured (but is still being watched for).
There were no clients on the local network side of the BEFSR81 at the time of the above example.
One wonders if this issue occurs for other hardware firewall/routers?
Occurance of this issue is pretty rare (perhaps once every couple of weeks), and it is not completley clear exactly what triggers it. Certainly, it could only occur during a relatively quite time on the external network, such that the final ethernet switch that merges multiple IP addresses (two in my case, and most home network cases) into the one line to the ADSL modem, has forgotten exactly where to send the packet. (I.E. it sends it to both the Ubuntu server and the BEFSR81).

Reference:The relevant section of my network diagram:



Other examples

Example 2: Three wireshark screen captures show IP address 125.46.42.93 looking around. There hasn't been any activity on the external network for quite awhile, so the switch does not know where to direct the first packet (number 39) and it sends it to both 209.121.28.186 and 209.121.28.192. As it should, 209.121.28.192 ignores the packet as it is not addressed there. Becuase the port is closed, 209.121.28.186 does not reply to the TCP SYN request, thus the switch doesn't learn anything new. About 0.08 seconds later 125.46.42.93 gets around to trying IP address 209.121.28.192, however the switch still sends the packet to both 209.121.28.192 and 209.121.28.186. Notice the different sequence number (not hightlighted). The claim is that packet 41 is a re-transmission of packet 40 from 209.121.28.186. Notice the TTL has been decremented.

A packet destined for 209.121.28.186:



A packet destined for 209.121.28.192:



The (I am claiming) re-transmitted packet. The original had also gone to the BEFSR81 at 209.121.21.186, which (I am claiming) re-transmitted it:




Example 3: Worth note in this example is that the firewall does not detect this re-transmitted packet as a problem. Only one wireshark screen capture is shown, detailing the re-transmitted packet. In this case the TCP SYN request is to the web server (packet 65). There has been no external network activity for a time prior to this request, so the switch sends the packet everywhere. Packet 67 is the re-transmitted packet from 209.121.21.186, which causes a second SYN ACK. Meanwhile the external network activity has allowed the network switch to figure out how to direct packets. The duplicate problem of packet 73 was caused by this double TCP session start.



References:
Cisco - LinkSys forum discussion.
Cisco - LinkSys BEFSR81 support page.