DHCP service issue on R80.40

[sam_huang]

Hello everyone, I recently encountered a very strange problem. The version is R80.40 + hotfix 126.In my network, the client cannot reach the DHCP server to obtain the IP through CheckPoint

       Recently, some VLANs cannot obtain IP normally. It is found through zdebug that dhcp is old seesion. Modify the kernel file according to sk123116. Operate and cancel the default dhcp relay and dhcp request, add custom service and Selected “Keep connections open after the policy has been installed”. add the interception record in the enforced Suspicious Activity Rules in and delet rule in tunnel & User Monitoring, and it has been normal for a few days after the policy is issued.

      Today, it happened again that the IP could not be obtained. The enforced Suspicious Activity Rules in tunnel & User Monitoring were blocked again, and after deleting the policy issued, the IP can be obtained normally. Have you encountered and resolved this situation?

tks all

[the_rock]

Hm...cant say I had seen that issue myself in R80.40 yet. Did debug show you exact message from that sk you referenced? What do you see if you do fw monitor just filtering for ports 67 and 68. For example

fw monitor -e "accept port(67) or port(68);"

[sam_huang]

Through packet capture, I found that the data belonging to port 67 in my data disappeared after entering the firewall. Use zdebug to find the display dropped by fw_handle_old_conn_recovery Reason: UDP packet that belongs to an old session;

[Wolfgang]

@sam_huang it's mandatory to follow Configuration of IPv4 BOOTP/DHCP Relay using new services even if you don't use the gateway as DHCP relay. Don't use the "old" services like "dhcp-relay", only dhcp-request or dhcp-reply has to be used. And you have to check twice that only rules with these services are matched by the DHCP traffic.

In the last years we had several cases with problematic DHCP connections. All are solved following the mentioned knowledgebase article.

[sam_huang]

When this failure first appeared, I did try to use the new dhcp service, dhcp_request and dhcp_reply two new services, but I added a new rule double src:any dst:any service:dhcp_request and dhcp_reply, the delivery policy still cannot be obtained To IP. Use zdebug to find that fw_handle_old_conn_recovery is still detected.

This makes me very strange. I don't know how to deal with DHCP traffic.

Or whether CheckPoint has any mechanism for UDP 67 service to solve this problem.
thanks

[Wolfgang]

You have to follow exact the mentioned sk.  dhcp-reply and dhcp-request both used in one rule is the wrong way. There is a detailed description how to configure the rulebase. If you follow the description in the sk and the problem still exists you can open a TAC case.

[the_rock]

@Wolfgang is absolutely correct, You need to follow that article if you have any hope of making this work...its literally like old school sk for VOIP traffic. If rules are wrong, it will not work, thats just how it is.