Seeing public IPs in arp table

I'm seeing some strange behavior with my OpenWRT router. I once checked the arp table and noticed an entry that contained a public IP address with a corresponding MAC address 00:00:00:00:00:00 entry on an interface eth0 that is down at the moment. This entry would stick around until something changed to interfaces.

I then found a way to reproduce how a certain public IP address got into the arp table, even though that does not explain how it gets there.

The uname -a output is as follows:
Linux 3.14.77 #7 SMP PREEMPT Sat Dec 12 17:00:31 CST 2020 armv7l GNU/Linux
This is a Chaos Calmer, r35193

The router has both LTE interface (usb0) and WAN interface (eth0). The failover priority is set to use WAN as primary connection, and LTE as secondary. However, in order to reproduce this issue, I would do the following:

Start with device on LTE connection (usb0 up), WAN cable (for eth0) unplugged.

I then start running the following loop script to give me output every second:

while true; do date; echo "WAN is `cat /sys/class/net/eth0/operstate`" ; echo "LTE is `cat /sys/cla
ss/net/usb0/operstate`"; echo "ARP table below:"; arp -n ; echo "Routing table:"; ip route show ; echo ; sleep 1; done

Normal output with LTE (usb0) up and unplugged WAN (eth0):

Thu Jan  7 15:10:17 EST 2021
WAN is down
LTE is up
ARP table below:
IP address       HW type     Flags       HW address            Mask     Device
Routing table:
107.125.217.72/29 dev usb0  proto kernel  scope link  src 107.125.217.X 
107.125.217.76 dev usb0  proto static  scope link  src 107.125.217.X 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1

Then I plug in WAN cable:

Thu Jan  7 15:10:46 EST 2021
WAN is up
LTE is up
ARP table below:
IP address       HW type     Flags       HW address            Mask     Device
192.168.100.1    0x1         0x2         d8:cb:8a:ce:de:xx     *        eth0
192.168.100.2   0x1         0x2         00:1e:4f:43:88:xx     *        eth0
Routing table:
107.125.217.72/29 dev usb0  proto kernel  scope link  src 107.125.217.X 
107.125.217.76 dev usb0  proto static  scope link  src 107.125.217.X 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 
192.168.100.0/22 dev eth0  proto kernel  scope link  src 192.168.101.19 
192.168.100.1 dev eth0  proto static  scope link  src 192.168.101.19

After a few moments, I unplug the WAN cable brining eth0 down, and just four seconds later, I noticed the public IP address of the openWRT router's manufacturer management IP address in the arp table - 63.250.XXX.XXX:

Thu Jan  7 15:10:51 EST 2021
WAN is down
LTE is up
ARP table below:
IP address       HW type     Flags       HW address            Mask     Device
63.250.XXX.XXX      0x1         0x0         00:00:00:00:00:00     *        eth0
Routing table:
107.125.217.72/29 dev usb0  proto kernel  scope link  src 107.125.217.X
107.125.217.76 dev usb0  proto static  scope link  src 107.125.217.X
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 

That entry sticks around for a LOT of time. I have not noticed it disappear unless again I plugged in the WAN cable thus bringing eth0 up and it populating with correct entries (local).
I have also seen NTP server addresses in the arp table at times.

Two questions:

  1. Are there any security implications in having those seemingly accidental public IP address entries in the ARP table?
  2. Have you seen those as well? How did you prevent those?

I have contacted the manufacturer but the response was brief: "Incomplete arp entries will eventually timeout. It is not really an inconvenience unless it interferes with proper operation.". I am not too satisfied with this answer as it does not explain if there are any security concerns with having those entries lingering in the system.

Any of your advice or input is appreciated. Thank you.

Very old, vulnerable, and unsupported.

OpenWrt firmware doesn't have such a management IP. If you are not running the official OpenWrt, then I guess you'll have to live with the response you got from the vendor.

1 Like

Thank you, @trendy
Yes, this is vendor-specific release, and their management IP. However, as a matter of fact, any public IP that OpenWRT device is trying to reach at the time of that failover, could get into the arp table. The big and important question is: is it that bad from the security standpoint (aside from the fact that the release itself is very old)?

There is no security risk from an incomplete entry in the arp table.

2 Likes