Support Center > Search Results > SecureKnowledge Details
Certain subnets and hosts behind NAT cannot obtain or renew IP addresses over DHCP in R77 Technical Level
Symptoms
  • Show All Information in the Entire Article

     

  • Certain subnets and hosts behind NAT cannot obtain or renew IP addresses over DHCP.

  • Issue with DHCP on certain subnets:

    • Certain subnets do not obtain a new IP address over DHCP, or renew DHCP lease time.

    • Kernel debug on cluster members ('fw ctl debug -m fw + drop') shows that the reply packets from the DHCP Server are dropped on the Inbound interface:

      fw_log_drop: Packet proto=17 IP_Address_of_DHCP_Server:67 -> VIP_Address_of_Cluster:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;


  • Issue with DHCP and Manual NAT in Security Gateway / ClusterXL / VSX Cluster:

    • Hosts on internal networks that are hidden behind Security Gateway's IP / ClusterXL's IP address are not able to obtain an IP address from DHCP Server when using DHCP Relay.

    • Kernel debug on Security Gateway / on cluster members ('fw ctl debug -m fw + drop') shows that DHCP Offer and DHCP Ack packets from DHCP Server are dropped on the Outbound interfaces towards the Hosts:

      ;fw_log_drop: Packet proto=17 IP_Address_of_DHCP_Server:67 -> 255.255.255.255:68 dropped by fw_conn_post_inspect Reason: fwconn_init_links (OUTBOUND) failed;

    • Kernel debug on Security Gateway / on cluster members ('fw ctl debug -m fw + nat xlate xltrc') shows that Unicast DHCP (non-relayed) packets from Hosts are dropped on the Inbound interface:

      ;fw_handle_first_packet: fwconn_key_init_links failed. Dropping packet;
      ;fw_log_drop_ex: Packet proto=17 IP_Address_of_Host:67 -> IP_Address_of_DHCP_Server:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;


  • Issue with DHCP and Manual NAT in ClusterXL Load Sharing mode:

    • Hosts on internal networks are sometimes not able to obtain an IP address from DHCP Server when using DHCP Relay.

    • Kernel debug on cluster member ('fw ctl debug -m fw + sync') that sends the initial DHCP Request to DHCP Server shows that the symbolic link is not synchronized to other members:

      ;FW-1: non_sync_vpn_ports: protocol: 17, DPORT 67, DST VIP_Address_of_Cluster - is in no hide, not syncing;;
      ;not synchronizing : non sync flag fwlddist_slink: d=8158 tuple= <0,Hex_IP_Address_of_DHCP_Server,43,Hex_VIP_Address_of_Cluster,43,11;0,Hex_VIP_Address_of_Cluster,43,Hex_IP_Address_of_DHCP_Server,43,11@0/0>

    • Kernel debug on cluster members ('fw ctl debug -m fw + drop') shows that the reply packets from the DHCP Server are dropped on the Outbound interface towards the Hosts:

      fw_log_drop: Packet proto=17 IP_Address_of_DHCP_Server:67 -> VIP_Address_of_Cluster:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (OUTBOUND) failed;


  • Issue with DHCP and Manual NAT in VRRP cluster:

    • Hosts on internal networks are sometimes not able to obtain an IP address from DHCP Server when using DHCP Relay.

    • Kernel debug on cluster members ('fw ctl debug -m fw + conn drop') shows that the reply packets from the DHCP Server are dropped:

      ;fw_log_drop_ex: Packet proto=17 IP_Address_of_DHCP_Server:67 -> Cluster_VRRP_Address dropped by fw_conn_inspect Reason: post lookup verification failed;
Cause
Show All Information in this section
  • Explanation for issue with DHCP on certain subnets

    The issue occurs in a scenario that involves multiple DHCP Relay interfaces (multiple interfaces facing multiple subnets that sent DHCP Discover packets).

    When a DHCP Offer is sent from the DHCP Server to DHCP Relay agent, it is sent to ClusterXL VIP address. By default, on Active member this DHCP Offer packet undergoes ClusterXL NAT "Fold" - the Destination IP address of the DHCP Offer packet is changed from ClusterXL VIP to the physical IP address of the receiving interface (the interface facing the DHCP Server), which is not the IP address of the DHCP Relay interface (the interface facing the Host that sent a DHCP Discover).

    This creates following connection link in Check Point kernel tables:

    [DHCP Server -> DHCP Relay interface agent's VIP address] -> [Translated: DHCP Server -> Physical IP address of receiving interface]

    Once additional DHCP packets from different DHCP Relay interfaces are received, link collisions occur in Check Point kernel tables because additional DHCP packets will be translated to same physical IP address of the receiving interface (the interface facing the DHCP Server).

  • Explanation for issue with DHCP and Manual NAT in Security Gateway / ClusterXL / VSX Cluster

    The drops of DHCP Offer and DHCP Ack packets occur in the following cases:

    • When IP ranges of both DHCP Relay interfaces (including Security Gateways' IP addresses) are behind NAT.
    • When the DHCP Request is sent at the same time through two different interfaces.
    • When NAT is applied to second DHCP Reply, behind NATed IP address toward broadcast IP address with the same Source/Destination ports, but with different originators.

    The drops of unicast DHCP (non-relayed) packets occur in the following case:

    • Incorrect connections are created in Check Point FireWall kernel when NAT is used.
  • Explanation for issue with DHCP and Manual NAT in ClusterXL Load Sharing mode
    • DHCP traffic is not configured to be synchronized between cluster members.
    • Stick Decision Function (SDF) is disabled.
  • Explanation for issue with DHCP and Manual NAT in VRRP cluster
    • In VRRP cluster, RouteD daemon modifies the source IP address of DHCP Request packets to internal VRRP address. Relevant Manual NAT rules must be created.

Solution
 Note: To view this solution you need to Sign In .