NSX DHCP Relay & DFW, how to create a rule for 0.0.0.0/68->255.255.255.255/67

[Chris-work4]

I'm looking at setting up DHCP relay for a segment.

its all straight forward but needs a rule in the DFW.

the instructions in the following work well

https://landy.dev/2020/04/27/setting-up-a-dhcp-relay-in-nsx-t-3-0/

checking log insight I see 

0.0.0.0/68->255.255.255.255/67

which passes through the clients rule of any any to udp-67

but I need to not have any 'any's in the rule base.

question is, how do I create a rule permitting 0.0.0.0 -> 255.255.255.255:67

I get an error if I add 0.0.0.0/32 (same for any subnet number) as a src address, but that is the address that gets logged so I'd expect to have a rule permitting just that q0 and not any other address.

255.255.255.255/32 is accepted just fine in the DFW rule base.

anyone any suggestions? 

[Perttu]

This is a kind of mind-blowing questions.

If you think carefully the purpose of DHCP you understand that it is to configure the host with an IP address and related information automatically.

So when a client asks for an IP address, it doesn't have a such yet, but the protocol designers wanted to use IP structure due to the TCP/IP-stack compatibility so they decided to put all zeros in src IP field in IP header. Hence 0.0.0.0.

Also the client cannot know address of a DHCP server beforehand, so destination is the universal broadcast address: that is all ones. Hence 255.255.255.255

But this is first time I hear someone asking how to make a firewall rule based on the IP header in DHCP Discovery/Request. However you should not do it like that because DHCP replies (ACKs) are not destined to address 0.0.0.0 (wouldn't make any sense), but to 255.255.255.255 as well.

( In stateful firewalls return packets are allowed in because their destination IP address matches to a source IP of an original connection establishing packet, but 0.0.0.0 doesn't work as a destination address )

So, you just must use any/any on that rule but just limit it for DHCP service, then the rule allows DHCP traffic only. It has to pass DHCP Offers and ACKs in as well..   

[Chris-work4]

that is fully logical.

the logs I see are what the fw has captured. so I'd expect to permit exactly what it has logged.

any/any seems wrong but binding to the DHCP ports at least provides some aspect security.

it is possible to have 255.255.255.255/32 in dst address which means just an any for the source which is a little better.

[Perttu]

The trouble is that when you normally have a rule for example for ping from say IP 10.10.10.10 to IP 8.8.8.8 in a stateful firewall then the same rule allows return traffic automatically with the help of established sessions mechanism. 

So when this firewall sees a ping packet (ICMP Echo Request) going from 10.10.10.10 to 8.8.8.8 it allows it through but also creates a new ICMP session into its established sessions table. So when any packet arrives, and its source is 8.8.8.8 and destination is 10.10.10.10, and packet type is ICMP Echo Reply, it matches to this session as a return packet and is allowed to go through. Same applies for any unicast traffic whether TCP or UDP protocols with subtle detail differences.

But in DHCP protocol the client discovers or requests for an address by broadcasting a DHCP packet to 255.255.255.255 and the server doesn't answer from that address but from its own address. Let's simulate DHCP protocol. Assume that DHCP server uses IP address 10.10.10.2 and offers address 10.10.10.5 for this particular client.

1. Client sends a DHCP Discover from 0.0.0.0 to 255.255.255.255 (to MAC FF:FF:FF:FF:FF:FF)
2. Server replies with a DHCP Offer from 10.10.10.2 to 10.10.10.5 (to client's MAC address)

As you see, the packets don't match together concerning their IP addresses. So the firewall has to think differently with DHCP. It might be that with a DHCP protocol selected it actually doesn't even care about IP addresses of return packets and destination 255.255.255.255/32 might actually work, but if it doesn't care, what's wrong with "any" anyway? In addition there is a special type of DHCP unicast request where the destination IP is DHCP server's IP. This is probably sent before the lease time expires, probably in the middle of it.  

I've set dozens of rules to allow DHCP in firewalls, but I've never thought about "limiting it". Also Spoofguard has additional options if you want to avoid rogue DHCP servers in your LANs. 

In summary: DHCP is special.