CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 6 of 6

Thread: DHCP drop on ClusterXL after R80.10 upgrade

  1. #1
    Join Date
    2017-05-29
    Posts
    11
    Rep Power
    0

    Default DHCP drop on ClusterXL after R80.10 upgrade

    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.

  2. #2
    Join Date
    2011-08-02
    Location
    http://spikefishsolutions.com
    Posts
    1,668
    Rep Power
    11

    Default Re: DHCP drop on ClusterXL after R80.10 upgrade

    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.

  3. #3
    Join Date
    2006-09-26
    Posts
    3,199
    Rep Power
    18

    Default Re: DHCP drop on ClusterXL after R80.10 upgrade

    Quote Originally Posted by jflemingeds View Post
    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?

  4. #4
    Join Date
    2011-08-02
    Location
    http://spikefishsolutions.com
    Posts
    1,668
    Rep Power
    11

    Default Re: DHCP drop on ClusterXL after R80.10 upgrade

    Like i said, i'm not sure if thats still valid for R80 and calling support is the best option.
    Last edited by jflemingeds; 2017-05-30 at 11:30.

  5. #5
    Join Date
    2017-05-30
    Posts
    1
    Rep Power
    0

    Default Re: DHCP drop on ClusterXL after R80.10 upgrade

    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:
    Click image for larger version. 

Name:	service_cfg.png 
Views:	1086 
Size:	19.1 KB 
ID:	1268

  6. #6
    Join Date
    2017-05-29
    Posts
    11
    Rep Power
    0

    Default Re: DHCP drop on ClusterXL after R80.10 upgrade

    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!!

Similar Threads

  1. DHCP Relay not working after upgrade to Version 77.20 on CP1140's
    By terri8369 in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 1
    Last Post: 2017-02-08, 15:24
  2. ClusterXL upgrade
    By zarcoff in forum Installing And Upgrading
    Replies: 1
    Last Post: 2012-09-20, 12:46
  3. UTM ClusterXL upgrade R65-R71.30
    By avilT in forum Installing And Upgrading
    Replies: 4
    Last Post: 2011-04-14, 05:27
  4. HFA40-Upgrade on UTM ClusterXL
    By avilT in forum Installing And Upgrading
    Replies: 4
    Last Post: 2009-04-29, 01:18
  5. R60-R65 upgrade ssl drop
    By kevindri in forum SNX - SSL Network Extender
    Replies: 4
    Last Post: 2008-02-04, 17:56

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •