Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Chris_W23
Participant

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

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?

10 Replies
PhoneBoy
Admin
Admin

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?

0 Kudos
Markusevc
Employee
Employee

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 ‘3rd 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 ‘3rd 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

Security Solutions Expert for Global Strategic Partners GSI/MSP/Telco & Consultancy Firms
Juan_Concepcion
Advisor

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

0 Kudos
SamiH
Contributor

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. 

0 Kudos
Juan_Concepcion
Advisor

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

0 Kudos
SamiH
Contributor

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. 

0 Kudos
Juan_Concepcion
Advisor

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

--Juan

0 Kudos
SamiH
Contributor

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

0 Kudos
Juan_Concepcion
Advisor

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.

0 Kudos
SamiH
Contributor

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. 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events