Possible bug Gaia 2.6.18 JHA Security Gateway and Standalone GA Take 237 - DHCP Relay

[Mike_Jensen]

It appears that I may have uncovered a bug in my R80.30 lab environment after installing  R80.30 Gaia 2.6.18 Jumbo Hotfix Accumulator Security Gateway and Standalone GA Take 237.

After this JHA is installed the DHCP Relay stops working.

I have a desktop VLAN that hangs off one interface of my HA cluster and then a server VLAN that is off of another.  The server VLAN contains the DHCP server.

With take 237 installed the desktops simply are not able to retrieve IP addresses.

A packet capture on the DHCP server itself shows the DHCP Discover and Offer over and over.  A packet capture on the desktop in question shows only DHCP discovers being sent and the offer never being received.

I did a tcpdump on the Check Point interface directly connected to the VLAN the DHCP server is on and opened in wireshark.  I see Boot Requests and Boot Reply's.

When I do a tcpdump on the Check Point interface directly connected to the desktop VLAN I only see Boot Request's.

I have verified proper DHCP Relay configuration and security policy.  Neither of which has changed.

Looking through logs in SmartConsole I don't see anything blocked.  All of my rules are set to log.

I have a No NAT rule configured so traffic between these two subnets is not NAT'ed.

It appears that this may be a roach motel scenario.

On the gateway when I run a fwl ctl zdebug |+drop during the dhcp  process I see the following:

@;39007;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=-1 ?:0 -> ?:0 dropped by fw ha_select_arp_packet Reason: CPHA replies to arp;
@;39481;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=17 192.168.0.30:67 -> 10.1.1.1:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
@;39549;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=17 192.168.0.30:67 -> 10.1.1.1:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
@;39652;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=17 192.168.0.30:67 -> 10.1.1.1:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
@;39788;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=17 192.168.0.30:67 -> 10.1.1.1:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;
@;39893;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=-1 ?:0 -> ?:0 dropped by fwha_select_arp_packet Reason: CPHA replies to arp;
@;40232;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=17 192.168.0.30:67 -> 10.1.1.1:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;

192.168.0.30 is the IP of my DHCP server and 10.1.1.1 is the VIP of my cluster (the DHCP Relay)

When I uninstall JHA Take 237 DHCP works properly.

Has anyone else encountered this yet?

Does Check Point have a process to report a possible bug discovered in a lab environment with gateways that don't have support?

[PhoneBoy]

Scenario 3 in this SK seems applicable: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
You might try the workaround listed there.

[Mike_Jensen]

I took a look at that SK but I am not sure.  I am not using SAML, remote access VPN, and 80.30 isn't specifically mentioned.

[PhoneBoy]

Sorry, wrong SK.
Try: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Mike_Jensen]

Yes, scenario # 3 in that SK indeed sounds like the issue I am encountering.  Unfortunately neither workaround resolved the issue.  

[Mike_Jensen]

I believe this issue may be caused by incorrect firewall policy rules for DHCP and for whatever reason this worked before the JHA.

I have uploaded my DHCP rules and the two temp rules I created for testing that allow DHCP to work again.

DC-01_192.168.0.30 is the DHCP server.

[PhoneBoy]

Looks like you’re using the legacy services.
Recommend you follow the guidance here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...,

[JanVC]

RFC1918 does not include broadcast address

check https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... for the suggested firewall rules

[JanVC]

also see https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Ruan_Kotze · Accepted solution]

Just for interest sake and not sure if it's at all relevant, but sk175206 was released today - "DHCP relay issues after upgrading to R80.40 take_120".

Different versions but perhaps the same code change in both Jumbo's.

[Mike_Jensen]

Very interesting.  Thank you for sharing.

[Mike_Jensen]

This resolved my issue in 80.30 as well.

[Robert_Sutton]

Thanks! I was getting nowhere with support on this after applying Take 125. This post lead me to the solution which required me moving my dhcp-request/dhcp-reply rules to the top of my ruleset. I had some "any" service rules above and the DHCP traffic was hitting those instead. Strange, that it had all worked fine before the Jumbo.