Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Mike_Jensen
Advisor
Jump to solution

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

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?

 
 

 

0 Kudos
1 Solution

Accepted Solutions
Ruan_Kotze
Advisor

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.

View solution in original post

0 Kudos
12 Replies
PhoneBoy
Admin
Admin

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

0 Kudos
Mike_Jensen
Advisor

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.

0 Kudos
PhoneBoy
Admin
Admin
0 Kudos
Mike_Jensen
Advisor

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

 

0 Kudos
Mike_Jensen
Advisor

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.

 

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
JanVC
Collaborator

RFC1918 does not include broadcast address

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

0 Kudos
JanVC
Collaborator
0 Kudos
Ruan_Kotze
Advisor

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.

0 Kudos
Mike_Jensen
Advisor

Very interesting.  Thank you for sharing.

0 Kudos
Mike_Jensen
Advisor

This resolved my issue in 80.30 as well.

0 Kudos
Robert_Sutton
Explorer

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events