Isc-kea 3.0.x dhcp server raw socket issue

Bugs
1

I’ve been chasing ghosts in my network for quite a while. Rarely, but frustratingly, clients would get an IP address from the wrong subnet. I also have very strong source IP firewall rules which makes those clients very unhappy. I’ve finally traced the issue to a bug in kea dhcp server.

Essentially, if you have an untagged VLAN on the same interface as a tagged VLANs, the tagged DHCP requests may be replied to from both the tagged DHCP scope and the untagged DHCP scope.

The current version in stream is 3.0.2. The current version in the community version is 3.0.3. The first production version with a fix is 3.2.0.

For fun, I built 3.2.0 through the vyos-build container and installed and everything immediately broke. The newest versions change the way interfaces need to be specified in the configuration to work correctly.

2

If you’re able, I would suggest also logging a bug on vyos.dev

If you don’t have an account/don’t want to, I’m happy to log the bug on your behalf.

Thank you for reporting it.

3

I can.

Any preference on how to detail it? It isn’t a simple package upgrade request. It has upgrade and downgrade compatibility issues.

4

I would just detail the issue you’ve encountered - and link to the details as you have in this thread.
How the fix is implemented would be up to the VyOS team - it will probably mean having a migration in place when people upgrade - quite a common thing.

5
6

Isn’t this the same as reported here: [solved] DHCP server hands out wrong addresses?

Looks like kea inherited the bugs from isc dhcpd…

7

Speaking of which…

Any particular reason for why not Kea is thrown out in favour of dnsmasq as backend?

Just like Kea it doesnt currently support dhcp-relay (Im guessing I Challenge Thee would be the best option today over isc-dhcp-relay who is like end of life by now?).

While dnsmasq supports the regular DHCP stuff incl option82 assignments along with a much easier syntax (for backend) and as it seems fewer odd bugs compared to Kea?

8

I worked around this issue using a macvlan as per https://lists.isc.org/pipermail/kea-users/2020-February/002630.html

eth1 is my untagged LAN which also has a number of tagged VLANs (eth1.1, eth1.2 etc)

set interfaces pseudo-ethernet peth1 address 192.168.xxx.250/32 # assign a /32 in the same subnet as the eth1 LAN
set interfaces pseudo-ethernet peth1 source-interface eth1

delete service dhcp-server listen-interface eth1 # tell kea not to listen raw on eth1
set service dhcp-server listen-interface peth1 # listen on the macvlan interface instead
set service dhcp-server listen-interface eth1.2
set service dhcp-server listen-interface eth1.3

10

This is very helpful and creative. Thanks!

Bad time to find out unifi has a bug in it that prevents editing DHCP guarding.

11

Some significant hacking around the unifi UI and I was able to force the dhcp guard.

The macvlan fix suggested here isn’t totally functional. ARP for the IP assigned to the macvlan will be replied to by the parent interface by default. That isn’t a huge problem but causes unnecessary fallback to broadcast DHCP on renewal and can potentially trigger unnecessary reassignment.

To avoid this set enable-arp-ignore on the parent interface, disable-arp-filter, enable-arp-ignore and source-validation ‘loose’ on the peth.

arp-ignore set the router to only reply to arp for IPs on the interface.
disabling arp-filter allows the peth to receive and reply to ARPs for MACs not detected on the peth.
source-validation loose allows the peth to ignore IP RPF.

set interfaces ethernet eth3 ip enable-arp-ignore
set interfaces pseudo-ethernet peth1 address ‘dhcp server IP/32’
set interfaces pseudo-ethernet peth1 ip disable-arp-filter
set interfaces pseudo-ethernet peth1 ip enable-arp-ignore
set interfaces pseudo-ethernet peth1 ip source-validation ‘loose’
set interfaces pseudo-ethernet peth1 source-interface ‘eth3’