Nixpkgs: Setting networking.firewall.checkReversePath prevents DHCP server to work

[vselin]

As a first step of requesting IP address from DHCP server host sends DHCP Discover packet on UDP 67. Source address in this request is 0.0.0.0.
If host with DHCP server is using NixOS and has networking.firewall.enable = true and networking.firewall.checkReversePath = true than netfilter rule in raw table

iptables -t raw -A PREROUTING -m rpfilter --invert -j DROP

drops packets with source address 0.0.0.0 silently.
Consequently DHCP session fails.

https://github.com/NixOS/nixpkgs/blob/release-15.09/nixos/modules/services/networking/firewall.nix#L103-L107

Setting networking.firewall.allowedUDPPorts or networking.firewall.trustedInterfaces has no effect on situation.

Also noteworthy is that setting sysctl net.ipv4.conf.default.rp_filter = 1 does not prevent DHCP to work.

[jgeerds]

Nice catch! Would be great if we could fix this for 15.09

/cc @edolstra

[bluescreen303]

net.ipv4.conf.default.rp_filter = 1 only has an effect on interfaces that are discovered _after_ setting it. Directly setting an interface or the all interface will probably have the same effect as this firewall rule.

also: there is no ipv6 equivalent to this sysctl, which is why using the firewall rule is preferred.

IMHO the solution would be to set networking.firewall.checkReversePath = false on DHCP _server_ machines. Running a DHCP server is a special case and probably needs some security-attention, like setting up the firewall manually.

Another solution would be to have an extra set of matchers in the raw table to give certain TCP/UDP ports free passage through the rpfilter, but that is probably too complicated/fine-grained.

[globin]

This actually affects running e.g. libvirt or lxc containers, as they start dnsmasq servers for DHCP on the container/VM. This probably is a more common use case where you don't actually handle the DHCP server yourself and it is not intuitive to check this firewall setting in this case. (Multiple people asking on IRC in recent times)

[bluescreen303]

I agree that's quite a common case. To fix this, we can change the default, document this behavior, or add an extra rule to the raw table (detect/accept dhcp before rpfilter). In case of the extra rule, we can hard-code 0.0.0.0 and udp 67, or make things more configurable.

I think adding 1 boolean (default true) option to add this exception is nicest.

[wkennington]

I wonder why this doesn't work for your dhcp setup but my dhcp server is
handing out leases fine with the default rpfilter settings. Does this only
affect virtual network interfaces some how?

On Mon, Oct 5, 2015, 01:25 Mathijs Kwik [email protected] wrote:

I agree that's quite a common case. To fix this, we can change the
default, document this behavior, or add an extra rule to the raw table
(detect/accept dhcp before rpfilter). In case of the extra rule, we can
hard-code 0.0.0.0 and udp 67, or make things more configurable.

I think adding 1 boolean (default true) option to add this exception is
nicest.

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/10101#issuecomment-145461663.

[globin]

The isc dhcpd at least is not affected but dnsmasq and radvd are. Another issue is the raw table not being flushed and not logging to the rejected packet log. I'm not sure we checked this on a non bridge interface and won't manage to do so today.

[domenkozar]

I've also hit this one when trying to get #10839 to work. Wasted lots of hours :)

[jgillich]

Why not move this option to networking.interfaces.<name>? Modules like libvirt and dhcp servers can then turn it off for their interfaces.

[domenkozar]

I'd really just turn this to false by default. It's very painful for virtualisation software.

[jgillich]

The feature sounds like a good idea in theory, and other distros like Ubuntu also enable it by default. Being able to disable it for specific interfaces would solve most issues, the only thing it doesn't cover is dynamically created interface.

[Gomez]

Hit this too on a kvm setup :( Buried many hours...

networking.firewall.checkReversePath = false

works as a workaround.

[Gomez]

Ok, the workaround is invalid. I need to turn firewall of to get dhcp working for my kvm guests.

[fpletz]

Ok, the workaround is invalid. I need to turn firewall of to get dhcp working for my kvm guests.

You also will have to allow port 67 UDP incoming to make DHCP work.

I have a local commit to fix the DHCP issue but keep the reverse path filtering enabled. Will get that into shape soon.

[domenkozar]

@fpletz please let's fix this :) It's super annoying, I lost another 20min before I remembered the switch has to be flipped.

[fpletz]

Ack! Thanks for the reminder.

[rasendubi]

(triage) @fpletz any update?

[fpletz]

Sorry guys, finally polished the code and opened a pull request for review: #17325