I am running ubuntu 16.04. I have ufw installed and enabled. I also have isc-dhcp-server installed. I have not opened up UDP port 67, yet DHCP clients still seem to be able to obtain DHCP leases from the server. Why is this? I have reviewed the IPTABLES that ufw creates, and it does have UDP port 68 opened for a DHCP client, but not UDP port 67 (as far as I can understand). It also does not appear to me as though ufw has configured IPTABLES to accept broadcast traffic. Is ufw supposed to allow or block broadcast traffic?
Does IPTABLES have some kind of special exception for UDP port 67 traffic?
Does a DHCP client fall back to broadcasting on UDP port 68 if it doesn't first get a response from broadcasting on UDP port 67? If so, this could make sense that the DHCP requests are making their way to the server, because then the UFW rule for allowing outgoing DHCP client requests would then allow incoming DHCP client requests.
The status of ufw status verbose
is
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
Best Answer
-- https://www.centos.org/forums/viewtopic.php?t=8728
It's often stated that this is because the DHCP server uses raw sockets. I think this phrasing is quite confusing. Some official ISC docs for their DHCP server use "raw sockets" as a broad term, because it can run on a number of different platforms where it must use a number of different interfaces. On Linux, there is more than one type that you might hear referred to as raw sockets. Some are affected by Linux iptables, and some are not affected by Linux iptables.
I'm confident that Linux' TCP/IP stack imposes some restrictions when sending packets with PF_INET+SOCK_RAW. My vague memory was that DHCP on Linux does not necessarily work with that type of socket, and might need to use "packet sockets" instead. Packet sockets work at a lower level. I'm confident that packet sockets are not affected by iptables.
-- https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html
This quote was written in the context of receiving packets. There is also evidence that this applies to sending packets, as you might expect.
It seems that iptables is one of the restrictions that applies to the TCP/IP stack, including to sending with PF_INET+SOCK_RAW.
https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html
And the evidence for the receive direction:
[NAT is performed by iptables]
-- https://lists.gt.net/iptables/user/62529#62529
Bonus griping: I think the term "packet filter" in my initial quote is a straight out abuse, albeit a long-standing one. Berkeley Packet Filter is a mechanism used to install a filter on a raw socket, e.g. so that it only receives packets on the DHCP port. I think ISC at times refer to "Linux Packet Filter" as if it was a type of raw socket itself. It's not, and you can actually use BPF on normal UDP or TCP sockets.