DHCP Server on Quantum 6600 doesn't answer

[kiadmin]

Hi

After struggling for many hours with such a simple task as setting up a DHCP-Server, I'm asking for help.

Check Point Quantum 6600 (single device, local management)

Sec. Management Srv.: R81.20 - Build 004

Software version: R81.20 - Build 011

Kernel: R81.20 - Build 013

The DHCP Scope is setup on a virtual VLAN-Interface on the physical port eth1-03. It was setup following the respective guide.

Everything was tested with different Access Control policies (UDP67/68) and with a temporary any/any/any setup, to exclude firewall influence. Providing a static IP of the subnet to the client leads to a functional network connection, so there is no "general" issue. Tcpdumping in expert mode yields incoming bootp packets requesting an IP-Address from the correct clients MAC address but NO answering packets. The logs of the cleanup rule shows dropped packets, when enabled. However, disabling the cleanup rule and enabling an "any-rule" shows no log entries (but still no answering packets in tcpdump).

Edit: "fw ctl zdebug drop" yields "fw_log_drop_ex: Packet proto=17 0.0.0.0:68 - > 255.255.255.255:67 dropped by fwpslglue_chain Reason: PSL Drop: CMI dropped connection;". As far as I can see, CMI seems to indicate towards the IPS as the culprit. I still don't have a clue how to setup allowance of DHCP in the IPS....

Is there anyone with another idea out there? I'm out of options. Are there any "hidden features" which may lead to drops?

Best regards,

Maik

[kiadmin · Accepted solution]

I found the solution in deletion of the connections table via "fw tab -t connections -x".

However this works until I perform changes in the access rule for DHCP. Afterwards, no IP until deleting the table again. So the problem in general is solved but has openend even more mysteries...

I would really love to hear some thoughts about that from the experts, anyway.

EDIT:

Using the great script to delete specific connection table entries, found here, I found the culprit for this strange behaviour. After deleting the broadcast entry (0.0.0.0,68,255.255.255.255,67,udp) from the table with the help of that script, the client was able to obtain the IP from the DHCP after modifying the access rule.

I'm no network expert, but this doesn't seem to be a correct behaviour!? So, maybe some kind of bug?

FINAL SOLUTION:

The DHCP-Rules (even if no Relay is used!) have to be exactly like they are described here (scroll down nearly to the bottom):

https://support.checkpoint.com/results/sk/sk104114