How do I allow DHCP relay from a non-Checkpoint host to pass the firewall?

[Chris_Williams]

Hello,

I am having issues getting DHCP relay to work through my R77.30 security management and gateway cluster.

I have a half dozen subnets that have the firewall as their default gateway, and the firewall acts as the DHCP relay for them, with the DHCP Server being located in a DMZ zone. This is working fine.

The problem is I have a new 3rd party VPN application. The VPN server acts as the DHCP relay for its clients and uses the same DMZ DHCP server to service its clients. I am unable to receive DHCP offers from the DHCP Server.

Wireshark packet captures on the DHCP server show the request coming in and a proper response going back out. The capture on the VPN server shows the DHCP offer coming from an incorrect IP - its coming from the public internet IP of my firewall instead of the DHCP server address. I have a NAT rule in place to keep the packets at their original addresses, but it seems to come out as the public IP, which is the final NAT rule. It kind of looks like the NAT rule is being ignored when its DHCP.

I've gone through SK104114 - Configuration of IPv4 BOOTP/DHCP Relay using new services and configured everything as instructed.

My rulebase is using the new dhcp-request and dhcp-reply services as per the above document.

I don't see a lot of this traffic in the tracker either, but I can see it in FW MONITOR and zdebug.

Any ideas?

[PhoneBoy]

What do your NAT rules look like?

Are the NAT rules automatic NAT rules or static ones?

Also, can you confirm what this setting is on your gateway object?

[Markusevc]

This was my experience running on R77.20
When the firewall needs to work as a DHCP relay for e.g. Microsoft Windows clients this “can” cause problems if the client is running Microsoft Firewall or similar. The returned DHCP packet will come from the cluster IP address and will be blocked as not statefull by the Microsoft Firewall running on the client.To correct this issue the option ‘Hide Cluster Members’ outgoing traffic behind the cluster’s IP Address’ needs to be unchecked. The problem is that this option is on the ‘3^rd Party Configuration’ tab, which is normally not shown when the ClusterXL option is selected (which is normally the case for a cluster).To enable the ‘3^rd Party configuration’ tab you have to uncheck ClusterXL in General Properties of the cluster. After unchecking this option you can access to 3rd Party Configuration options (where it was supposed to be ClusterXL options), uncheck ‘Hide Cluster Members’ outgoing traffic behind the cluster’s IP Address’ option.
After this go back into General Properties and check ClusterXL again. After this change, DHCP-relay and Windows will work like a charm.

In R77.30, this function is replaced with Sticky Decision Function (SDF)
GW Cluster > CluserXL > Advanced >  Use Sticky Decision Function

In addition take also a look at sk97566

Good luck !!!

R77.20

 

R77.30

[Juan_Concepcion]

Ensure that when you configure the dhcp relay interface in GAIA that you're manually entering the cluster vip and not leaving it set to automatic.  This is very important.

If you do a tcpdump -nni at command line do you see the traffic go out and come back successfully??

--Juan

[SamiH]

I have the same situation where external device sends DHCP requests as a relay and they are received and answered at the other interface in gateway. I can see the DHCP Offer coming to correct interface, but after that it disappears completely. Haven't had time to trace it in Gaia yet. 

In addition I see the original request first being transferred through non-NATted packet and after that the same query tries to come in NATted with gw external ip and that's when the gw drops that second request, since the UDP packet contains original non-NATted source ip. 

[Juan_Concepcion]

Make sure you don’t have NAT enabled between the relay and the dhcp server, it should be just a normal routed connection once the relay sends request to dhcp server.

--Juan

[SamiH]

I think there isn't, even though the requesting net is hidden when (with network automatic NAT rules) connecting to internet, but when connecting to internal resources (which work with static ip), it doesn't use NAT. 

[Juan_Concepcion]

From the relay host can you communicate successfully with the dhcp server (ping or something of the sort)??

--Juan

[SamiH]

Yes, that works okay. All devices can ping each other and without dhcp everything seems to work fine.

[Juan_Concepcion]

If user connects to 3rd Pary VPN application and then that application in turn does a bootp/dhcp request out to the dhcp server then the firewall must have dhcp relay interface enabled on the interface facing he 3rd Party VPN application if i'm understanding the flow correctly.

[SamiH]

That wasn't actually the picture, but MPLS network trying to get through firewall to get an address. Anyway, managed to fix it via instructions in sk104114 (which support gave me), where I just had to change the rules and implement rules 2 and 4 in the example. The rule number four had to be changed to letting dhcp server to communicate to dhcp relay outside. There has to be explicit rules for dhcp request/reply.

All in all I had to do changes to kernel parameters, install one add-on and remove ports from table.def in addition to those rules.