DHCP drop on ClusterXL after R80.10 upgrade

[julzor]

Hi,

I'am facing some nasty DHCP problems and i know how to resolve it.

Right after we upgraded from R77.30 to R80.10 (Both Mgmt servers and Gateways), the DHCP was not working anymore.

The topology : (Clients on multiple subnets) <-> (Some DHCP Relay) <-> (2x CP 12600 ClusterXL) <-> (DHCP Server)
I have DHCP Relay on a lot of different hardware : Cisco routers, CheckPoint firewalls, Cisco WLC, Pulse Secure SSL VPN, ...

I quickly found that since R80.10, the default "DHCP behavior" for ClusterXL is forced to be used with the "DHCP New Services" (dhcp-request, dhcp-reply).

So i changed my rulebase, i kicked out the legacy DHCP services and replaced them by the new ones (From ANY, To ANY, dhcp-request/dhcp-reply).

Here began the weird stuff : it actually fixed the DHCP, but... only for "some" subnets.

There is no "logic" about which subnet receives IP address correctly and those who don't.
On a specific CheckPoint firewall, all of the subnets received their IP address, except... one.

The problem obviously comes from the CP12600 Cluster, which show those messages :

fw ctl zdebug + drop | grep (DHCP-SERVER-IP = xxx.xxx.xxx.xxx)
[...]
;[cpu_9];[fw4_2];fw_log_drop_ex: Packet proto=17 xxx.xxx.xxx.xxx:67 -> 10.9.32.9:67 dropped by fw_conn_post_inspect Reason: Handler 'dhcp_request_code' drop;
;[cpu_9];[fw4_2];fw_log_drop_ex: Packet proto=17 xxx.xxx.xxx.xxx:67 -> 10.9.32.9:67 dropped by fw_conn_post_inspect Reason: Handler 'dhcp_request_code' drop;
;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 xxx.xxx.xxx.xxx:67 -> 10.9.32.5:67 dropped by fw_conn_post_inspect Reason: Handler 'dhcp_request_code' drop;
;[cpu_8];[fw4_3];fw_log_drop_ex: Packet proto=17 xxx.xxx.xxx.xxx:67 -> 10.9.96.1:67 dropped by fw_conn_post_inspect Reason: Handler 'dhcp_request_code' drop;
[...]

So basically, the request get to the DHCP Server, but then the firewall dropps the "Reply".

Since he doesn't even act himself as a Relay, he should just "route" and "firewall" those packet, but it looks like a kind of inspection is failing.

By the way, i already tried a lot of stuff, but i don't find any real solution to the issue.

Does everyone has an idea about what the problem might be?
What is the meaning of those errors?

Thank you.

[jflemingeds]

did you run though sk110021 when you were on r77.30? I don't know if thats still valid for r80.10 or not. Looks like it points to .def files needing updated eitherway.

I think you're best off going the support route.

[cciesec2006]

did you run though sk110021 when you were on r77.30? I don't know if thats still valid for r80.10 or not. Looks like it points to .def files needing updated eitherway.

I think you're best off going the support route.

I thought the SK110021 is very specific that it only applies when you upgrade from R77.20 to R77.30?

[jflemingeds]

Like i said, i'm not sure if thats still valid for R80 and calling support is the best option.

[edale]

I've seen this before. The drop message "Reason: Handler 'dhcp_request_code' drop;", indicates that the DHCP Replies from the server are being matched against your "dhcp-request" rule, instead of your "dhcp-reply" rule.

I suspect the root cause is in the configuration of your "dhcp-request" service in SmartConsole. In the security policy, double-click on dhcp-request to edit the service, and go to the "Advanced" section. The "Match" field must contain "dhcp_req_match". Also be sure to disable "Synchronize connection on cluster".

Also check the dhcp-reply rule for the same issue. The match field should be "dhcp_rep_match" here.

Let me know if this fixes your issue. Screenshot below:

[julzor]

Hi,

I fixed the issue before viewing all the answers.

Actually, the solution was quite "simple", but hard to find...

The problem was that some DHCP Relay "Session" established using the legacy services were still in the connections table.
So when i pushed the policy using the new services, he dropped the packet because of this.

Right after the push of the new services, some (small) networks didn't do any DHCP request for the first 40 seconds (standard UDP session timeout), and worked fine directly with the new services.
Some other bigger networks never stop to forward DHCP (15k clients on the WiFi...), so the session never ends.

I had to delete the problematics DHCP-Relays for few minutes, then reconfigure them, and everything eventually worked.

By the way, in a SK (don't remember which one), it was specified something like : "if everything is correctly configure for the news services, but it's still not working, clear the connections table".
I couldn't do it because it's a Datacenter firewall and i can't break the servers networks, but it was the problem. I just found a workaround that fit my requirements.

Thank you anyway for the replies!!