Incusbr0 DHCP isolation (nftables rules)

Incus
,
1

Today I run into an issue where one of my network clients got an IP assigned from my incus server instead of network router :thinking: Kind of a wired situation but it happened for some reason.

Looking into incus default nftables rules it seems to me there is no isolation on dropping any DHCP requests coming from the outside world or public interfaces.

I’m not that firm with nftables and wondering if someone might can give an example how to do this with nftables?

2

Several services use dnsmasq as a way to provide DHCP services to specific network interfaces.

You can check /etc/dnsmasq.d-available/ for any relevant configuration. For example, I also have virt-manager installed. Here, libvirt is requesting other dnsmasq processes not to touch that specific interface. If you install Waydroid, you get an additional such file.
There’s no such Incus file though.

$ cat /etc/dnsmasq.d-available/libvirt
bind-interfaces
except-interface=virbr0

Second, check in /var/lib/incus/networks/ (as root) for the available networks that are managed by Incus. You can identify whether it was Incus that gave a specific lease.

3

Also, use

sudo lsof -n -i -sTCP:LISTEN

to view the network interfaces that Incus’ dnsmasq is listening.
It should show the IP addresses of those networks, and you can correlate with the output of the network interfaces that are managed by Incus.

incus network list

There should be no dnsmasq owned by the incus user that is listening to a network interface that is not managed by Incus.

4

Checked the suggested areas.

There is no such directory on my system and there is only one process listed on my host for dnsmasq owned by incus.

All my home networks are in the 192.168… range and only incus is using 10.102… Which made it obvious to me that the lease what served from incus dnsmasq. Where else should that client get a 10.102… IP assigned from?

General idea is to drop incoming DHCP requests from outside world which shouldn’t be such hard or better someone has done it for sure just need to find it :wink:

5

It does not make sense that a device on your LAN got an IP address from the incusbr0 managed interface (private bridge). Something else went wrong and we would need the output of commands to figure out what went wrong.