WHY ARP has ip bouncing from device to another

[ikkeT]

Hi,

I have had some unstableness in my opnsense for over a year now. After long digging, I found it is likely caused by ARP jumping IP from device to another in my laptop. Why does this keep happening?

I have laptop with two interfaces, wlan and usbdongle ethernet when in wire:

Code Select Expand

2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6a:cb:3f:c6:c9:09 brd ff:ff:ff:ff:ff:ff permaddr 9c:67:d6:0f:8f:c0
    inet 192.168.117.59/24 brd 192.168.117.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 4000sec preferred_lft 4000sec
    inet6 fe80::66f9:af89:6d28:703a/64 scope link tentative noprefixroute
       valid_lft forever preferred_lft forever
4: enp0s13f0u1u2u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 48:65:ee:15:7f:c2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.117.56/24 brd 192.168.117.255 scope global dynamic noprefixroute enp0s13f0u1u2u1
       valid_lft 2936sec preferred_lft 2936sec
    inet6 fe80::4993:59f0:25d:240a/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Both MACs are fixed with separate IP addresses in KEA reservations page:

192.168.117.0/24   192.168.117.56   48:65:ee:15:7f:c2   satechi
192.168.117.0/24   192.168.117.59   6a:cb:3f:c6:c9:09   iklap

Satechi is the usbdongle brand. Iklap is the Fedora laptop name.

While I have the both connected (docking), I see this bouncing in OPNSense:

Code Select Expand

arp: 192.168.117.56 moved from 6a:cb:3f:c6:c9:09 to 48:65:ee:15:7f:c2 on igb2
arp: 192.168.117.59 moved from 6a:cb:3f:c6:c9:09 to 48:65:ee:15:7f:c2 on igb2
arp: 192.168.117.56 moved from 48:65:ee:15:7f:c2 to 6a:cb:3f:c6:c9:09 on igb2
arp: 192.168.117.56 moved from 6a:cb:3f:c6:c9:09 to 48:65:ee:15:7f:c2 on igb2
arp: 192.168.117.56 moved from 6a:cb:3f:c6:c9:09 to 48:65:ee:15:7f:c2 on igb2

And I believe that will drain the opnsense out of mem soonish. What causes the IP to bounce outside of their mac? I suspect it's somehow the laptop sending dhcpc query with laptop name in it (NetworkManager), which then KEA uses to overrule what Reservations page is saying.

Is this a bug somewhere? Why does KEA allow ip to go from MAC to another not respecting reservations?

Any idea what should be done here? It's annoying needing to toggle wlan off each time while docking due this. Do I have some misconfig in a) in my Fedora laptop or b) KEA, or c) bug somewhere?

[Patrick M. Hausen]

Services > Kea > Subnets > edit your subnet and remove that check mark:

[ikkeT]

thanks, makes sense now that you point it out :D

[chemlud]

Services > Kea > Subnets > edit your subnet and remove that check mark:

...eeehm, this was introduced when?

[Patrick M. Hausen]

...eeehm, this was introduced when?

To my knowledge when Kea was first added to OPNsense. Client-ID instead of MAC is the default behaviour for Kea.

[chemlud]

Ah,, sorry, forgot my Alzheimers medis this morning... ISC was the old *sense standard, KEA was introduced as possible replacement.

What is the current status on DHCP in the roadmap of OPNsense? Will ISC persist? I think I read about something going to be blown away soonish...

[Patrick M. Hausen]

What is the current status on DHCP in the roadmap of OPNsense? Will ISC persist? I think I read about something going to be blown away soonish...

ISC is going to be removed.
DNSmasq DHCP is the recommended replacement for small installations.
Kea is the recommended replacement for enterprise environments (once it reaches feature parity).

I don't know about the timeline from the top of my head.

[ikkeT]

Damn, then I made the migration from dnsmasq to kea for nothing, I thought kea was the way forward. Well it works now...

[franco]

> Damn, then I made the migration from dnsmasq to kea for nothing

But not on our end? Dnsmasq DHCP is coming in 25.1.6 so if you already have moved your DHCP to OPNsense you just need to reconfigure from there.


Cheers,
Franco

[ikkeT]

I had dnsmasq in use in opnsense, and moved the config to kea and unbound. It's no biggie just one evening useless work. I don't need to do anything to keep the current setup as it sounds.

[DEC670airp414user]

interesting.  I've noticed weirdness since I've used kea.

i turned this setting off. we will see if that clears up some it

"ISC is going to be removed.
DNSmasq DHCP is the recommended replacement for small installations."

i wish i had read/ known that before i moved to kea...

[alex303]

Services > Kea > Subnets > edit your subnet and remove that check mark:

Sry to hijack this thread but, are these client identifiers unique for each device? Can this feature of kea enhance security in a sense that if someone spoofs the mac address of device, he still wont be able to connect and receive ip address from dhcp server because the client identifier doesnt match ? Assuming of course that dhcp static mapping is in full use.

[franco]

> i wish i had read/ known that before i moved to kea...

I think we are all on the same side here.

[Patrick M. Hausen]

I think we are all on the same side here.

Then why introduce YAS (yet another service)? What can DNSmasq do that Kea cannot?
Why do we need anything but Kea and BIND? Special filtering services like AGH notwithstanding, of course.

[franco]

> What can DNSmasq do that Kea cannot?

It's much more reliable and straightforward and compact. Dnsmasq can do DNS, DHCPv4/6 and RA (and register your DHCP leases in DNS). Everything is already implemented without too much effort in OPNsense development release. The only thing it cannot do is prefix delegation and that's why there will be Kea v6 eventually.

To outline this a bit more for 26.1 we will have a compact default setup using DHCP via Dnsmasq or an optional complicated one using Kea/radvd for all things HA and of grander scale.


Cheers,
Franco