Threaded Mode | Linear Mode

Shoikan · 2016-10-17, 08:46

Hi,

We've run into some problems that took us a while to troubleshoot with iPXE. Imagine a random setup with a DHCP server, a DHCP relay, and a client. All is set up as one normally would. The following flow will then proceed:

Client performs a DHCP discover
DHCP relay passes on discover to DHCP server
Server receives DHCP discover
Server sends DHCP offer
Relay passes on offer to client
etc.

This all works nicely if the DHCP relay is a well behaving relay, or the client is not too picky. In our case, we use a Checkpoint firewall as a relay. The Checkpoint firewall is.. euhh.. not quite well behaved: it sends the packets on to the client on a random non-privileged port (>1024). So you get:

Discover
Offer
Discover
etc..

When checking the iPXE source we see there is a hard requirement that the source port that the offer and ack packets are sent from to the client HAVE to be on the BOOTPS port (from: https://git.ipxe.org/ipxe.git/blob/maste...dp/dhcp.c, line 400):

Code:

if ( ip.s_addr && ( peer->sin_port == htons ( BOOTPS_PORT ) ) &&

.

Now, if I check the RFC, I couldn't find a solid confirmation that this behaviour is a requirement. Apparently, the client in the OS (happens to be Linux) is more lenient and accepts it just fine.

So I wonder: is Checkpoint wrong in answering from an odd port, or is iPXE unnecessarily picky in this case?[/code]

Shoikan · 2016-10-17, 09:00

Hi,

We ran into an interesting 'feature' from iPXE. If the source port of the DHCP offer or ack packets come from another source port than the BOOTPS port, iPXE ignores them. This causes it to never properly get a lease.

Normally, if you use a relay and it's a well behaved relay, it will use the proper ports to relay from. But we use a Checkpoint firewall, which insists on using a random non-privileged port (>1024) when passing the offer or ack packets to the client.

When looking at the iPXE source code, we found the following at line 400:

Code:

if ( ip.s_addr && ( peer->sin_port == htons ( BOOTPS_PORT ) ) &&

And there's another such line for the ACK phase. This enforces that the source port of the offer should be the BOOTPS port. The effect in our case is discover -> offer -> timeout -> discover -> offer -> timeout -> etc.

The client in the OS (linux in our case) doesn't seem to care and will work just fine (discover -> offer -> request -> ack).

I have checked the RFC but couldn't find a hard requirement that the source port should be the BOOTPS port (but not 100% sure I didn't miss it in the RFC). So my question is: is iPXE too strict, or is Checkpoint being... euhhh.. 'sub-optimal' here?