> Source: [sk97642](https://support.checkpoint.com/results/sk/sk97642)
# sk97642 - Troubleshooting DHCP Relay Issues
| Property | Value |
|----------|-------|
| Solution ID | sk97642 |
| Date Created | 2013-12-10 |
| Last Modified | 2022-12-20 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R81.20, R81.10 (EOS), R81 (EOS) |
| OS | Gaia |
## Solution
**Table of Contents**
* DHCP Relay
* Various Scenarios
* Scenario 1: How to configure DHCP Relay for a specific Virtual System on Gaia OS
* Scenario 2: DHCP Request packets are silently dropped by Security Gateway / Cluster
* Scenario 3: ClusterXL NAT for DHCP Relay traffic fails in ClusterXL HA mode on Gaia OS
* Scenario 4: ClusterXL configured as DHCP Relay drops DHCP reply packets sent from DHCP Server
* Scenario 5: How to change the value of 'Max Hopcount' for DHCP Relay on Gaia OS
* Scenario 6: "Connection contains real IP of NATed address" log for dropped 'DHCP Offer' packets when host tries to get IP address via DHCP
* Scenario 7: DHCP Relay does not work because NAT of DHCP Relay payload was enabled
* Scenario 8: DHCP-Relay does not work - Gateway seems to be sending ARP-requests using incorrect interface
* Scenario 9: DHCP Relay stopped working after VLAN interfaces were deleted
* Scenario 10: routed on Gaia does not forward BOOTP DHCP Relay packets smaller than 300 bytes
* Scenario 11: Configuring DHCP Relay on VSX via 'sysconfig' command stops DHCP Relay on other Virtual Systems
* Scenario 12: ClusterXL configured as DHCP Server drops DHCP Request packets with "Connection contains real IP of NATed address" log
* Scenario 13: DHCP Discover packets are not relayed to DHCP Server
* Scenario 14: DHCP Relay does not work after changing interface configuration
* Scenario 15: DHCP Relay does not work in ClusterXL on one or more interfaces
* Scenario 16: After upgrade, cannot use DHCP relay
*** ** * ** ***
DHCP Relay {#DHCP Relay}
========================
BOOTP/DHCP Relay extends Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) operation across multiple hops in a routed network. In standard BOOTP, all interfaces on a LAN are loaded from a single configuration server on the LAN. BOOTP Relay allows configuration requests to be forwarded to and serviced from configuration servers located outside the single LAN.
When an interface configured for BOOTP Relay receives a boot request, it forwards the request to all the servers in its server list. It does this after waiting a specified length of time to see if a local server answers the boot request. If a primary IP is specified, it stamps the request with that address, otherwise it stamps the request with the lowest numeric IP address specified for the interface.
For a more comprehensive discussion, refer to *Gaia Administration Guide* \> Chapter DHCP Relay - BOOTP Interfaces.
**Related solutions:**
* [sk98839 - Configuration of IPv4 BOOTP/DHCP Relay using legacy services](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98839)
* [sk104114 - Configuration of IPv4 BOOTP/DHCP Relay using new services](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk104114)
Various Scenarios {#Various Scenarios}
======================================
**There are quite a number of scenarios, in which you may encounter DHCP Relay issues. Scenarios, in which the relay is on the Security Gateway, that we have encountered and dealt with are detailed below.**
Check Point recommends to always [upgrade to the most recent version](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=359).
Scenario 1 {#Scenario 1}
------------------------
**Title: *How to configure DHCP Relay for a specific Virtual System on Gaia OS***
n Gaia OS, the **RouteD** daemon handles DHCP Relay traffic.
Follow the steps below to configure DHCP Relay for a specific Virtual System on Security Gateway / ClusterXL in VSX Mode
**Table of Contents:**
* Configure VSX Gateway (non-cluster configuration)
* Configure ClusterXL in VSX Mode
* Documentation
### Configure VSX Gateway (non-cluster configuration) {#Single Gateway}
1. Go to from Clish to Expert mode: **`HostName> expert`**
2. Determine the VSID of a specific Virtual System, on which you want to enable the DHCP Relay:
**`[Expert@HostName:0]# vsx stat -v`**
3. Determine the IP address of the interface, on which you want to enable the DHCP Relay for that Virtual System:
**`[Expert@HostName:0]# vsenv `*VSID***
**`[Expert@HostName:`*VSID* `]# ifconfig `*name_of_VS_interface_facing_DHCP_Client***
**Note:** The IP address seen in this output is allocated from VSX Internal Communication Network "Private" range (by default, 192.168.196.0/28).
4. Exit from Expert mode to Clish: **`[Expert@HostName:`*VSID*`]# exit`**
5. Enable DHCP Relay:
1. Go to the context of involved Virtual System:
**`HostName> set virtual-system `*VSID***
2. Set the *physical* private IP address as Primary Address:
**`HostName> set bootp interface `*name_of_VS_interface_facing_DHCP_Client*` primary `*Private_IP_Address*` wait-time on`**
**Notes:**
* Default '`primary `*Private_IP_Address*' is the Lowest IP address on the interface.
* If the '`primary `*Private_IP_Address*' is not specified explicitly, then the IP address configured in SmartDashboard will be used. As a result, DHCP Relay traffic will not be processed correctly (FW Monitor will show that traffic does not get past Post-Inbound "I").
3. Configure BOOTP properties for the involved interface:
**`HostName> set bootp interface `*name_of_VS_interface_facing_DHCP_Client*` relay-to `*IP_Address_of_DHCP_Server*` on`**
6. Check the configuration: **`HostName> show bootp interfaces`**
7. Save the configuration: **`HostName> save config`**
8. Test the DHCP Relay traffic.
### Configure ClusterXL in VSX Mode {#ClusterXL}
1. Go to from Clish to Expert mode: **`HostName> expert`**
2. Determine the VSID of a specific Virtual System, on which you want to enable the DHCP Relay:
**`[Expert@HostName:0]# vsx stat -v`**
3. Exit from Expert mode to Clish: **`[Expert@HostName:`*VSID*`]# exit`**
4. Determine the cluster Virtual IP address configured on the involved interfaces, on which you want to enable the DHCP Relay for that Virtual System:
1. Connect with SmartDashboard to Security Management Server / Domain Management Server that manages that Virtual System.
2. Open Virtual System object.
3. Go to '`Topology`' pane.
4. Find the relevant the cluster Virtual IP address of involved interface.
5. Click on '`Cancel`'.
5. Enable DHCP Relay:
1. Go to the context of involved Virtual System:
**`HostName> set virtual-system `*VSID***
2. **This step applies only to VS:**
Set the Cluster Virtual IP address as Primary Address:
**`HostName> set bootp interface `*name_of_VS_interface_facing_DHCP_Client*` primary `*Virtual_IP_Address_of_involved_interface*` wait-time on`**
**Notes:**
* If the '`primary `*Cluster_Virtual_IP_Address*' is not specified explicitly, then the IP address configured in SmartDashboard will be used. As a result, DHCP Relay traffic will not be processed correctly (FW Monitor will show that traffic does not get past Post-Inbound "I").
3. Configure BOOTP properties for the involved interface:
**`HostName> set bootp interface `*name_of_VS_interface_facing_DHCP_Client*` relay-to `*IP_Address_of_DHCP_Server*` on`**
6. Check the configuration: **`HostName> show bootp interfaces`**
7. Save the configuration: **`HostName> save config`**
8. Test the DHCP Relay traffic.
**Applies To:** 00938860 , 01112639 , 01005777 , 01163971 , 01176689 , 01153006 , 01170333
*** ** * ** ***
Scenario 2 {#Scenario 2}
------------------------
**Title: *DHCP Request packets are silently dropped by Security Gateway / Cluster***
**Symptoms:**
* DHCP Request packets are silently dropped by Security Gateway / Cluster running on Gaia OS before being forwarded to the DHCP Server.
* The following messages appear in `/var/log/messages`:
`routed[`*PID* `]: bootpgw: Relay agent configured in a cluster but relay gateway address `*W.X.Y.Z*` is not a cluster address. Relay Agent disabled`
`routed[`*PID*`]: bootpgw: Relay agent configured in a cluster but configured primary address not found. Relay agent disabled`
* These messages appear in `/var/log/messages`:
`routed[`*PID* `]: task_send_packet_iovec: task BOOTPGW.0.0.0.0+67 socket `*X*` length `*Y*` if_index 0 from `*Primary_IP_Address*` to `*DHCP_Server_IP_Address*`+67: Invalid argument`
**Cause:**
Wrong configuration for DHCP Relay 'Primary Address' - either IP address was not configured at all, or wrong IP address was configured.
**Solution:**
Follow these steps:
1. Connect with your web browser to Gaia Portal of the relevant Security Gateway / each Cluster member.
2. Make sure that '`View mode`' is set to '`Advanced`' (upper right corner).
3. Make sure that you acquire the configuration lock (icon on the top toolbar - near the '`Sign Out`').
4. Go to '`Advanced Routing`' pane - go to '`DHCP Relay`' section:
5. In the '`BOOTP/DHCP`' section, click on '`Add`' button - '`Add BOOTP / DHCP Relay`' window opens:
6. In the '`Interface:`' field, select the interface, through which the DHCP packets will be received from / sent to hosts on the network (in our example - *eth2* ):
7. In the '`Primary Address:`' field, enter the following IP address:
* **On Security Gateway** - enter the **primary physical IP address** that was configured on the selected interface (in our example - *20.20.20.11* ):
* **On each Cluster member** - enter the **Cluster Virtual IP address** that was configured on this interface in Cluster Topology.
Run the '`cphaprob -a if`' command on the cluster members (in our example - *20.20.20.20* ):
```
[Expert@HostName]# cphaprob -a if
Required interfaces: 1
Required secured interfaces: 0
eth0 UP non sync(non secured), multicast
eth2 UP non sync(non secured), multicast
eth1 UP sync(secured), multicast
Virtual cluster interfaces: 2
eth0 192.168.204.20
eth2 20.20.20.20
[Expert@HostName]#
```
8. In the '`Relays`' section, click on '`Add`' button - '`Add Relay`' window opens:
* Enter the IP address of the DHCP Server, to which the DHCP packets from hosts will be forwarded/relayed (in our example - *192.168.204.3* ).
* Click '`OK`'.
9. Check the configuration in the '`Add BOOTP / DHCP Relay`' window and click on '`Save`' button: *Based on our examples* :
>
> **Security Gateway:**
>
> 
>
> **Cluster members:**
>
> 
10. The DHCP Relay configuration is added in the '`DHCP Relay`' section: *Based on our examples* :
>
> **Security Gateway:**
>
> 
>
> **Cluster members:**
>
> 
11. You can also check the DHCP Relay configuration on the CLI:
* **In Clish:**
**`HostName> show bootp interfaces`**
*Based on our examples* :
**Security Gateway:**
```
BOOTP Relay Interfaces State
Interface eth2
Flags:
Max Hopcount: 4
Wait Time: 0
Primary Address: 20.20.20.11
Gateway Address: 20.20.20.11
Relay To: 192.168.204.3
```
**Cluster members:**
```
BOOTP Relay Interfaces State
Interface eth2
Flags:
Max Hopcount: 4
Wait Time: 0
Primary Address: 20.20.20.20
Gateway Address: 20.20.20.20
Relay To: 192.168.204.3
```
* **In Expert mode:**
**`[Expert@HostName]# grep routed /config/db/initial | grep bootpgw`** *Based on our examples* :
>
> **Security Gateway:**
>
> ```
> routed:instance:default:bootpgw:interface:eth2 t
> routed:instance:default:bootpgw:interface:eth2:relayto:host:192.168.204.3 t
> routed:instance:default:bootpgw:interface:eth2:primary 20.20.20.11
> ```
>
> **Cluster members:**
>
> ```
> routed:instance:default:bootpgw:interface:eth2 t
> routed:instance:default:bootpgw:interface:eth2:relayto:host:192.168.204.3 t
> routed:instance:default:bootpgw:interface:eth2:primary 20.20.20.20
> ```
12. If the issue persists, then enable the '*Wait for Clusterin* g' setting - follow the instructions in the [sk92322 - Neighborship for OSPF, BGP, RIP, and PIM in Gaia Cluster is formed with Physical IP addresses upon a reboot](http://supportcontent.checkpoint.com/solutions?id=sk92322).
**Applies To:** 00938860 , 01005777 , 01112639
*** ** * ** ***
Scenario 3 {#Scenario 3}
------------------------
**Title: *ClusterXL NAT for DHCP Relay traffic fails in ClusterXL HA mode on Gaia OS***
**Symptoms:**
* Certain subnets do not obtain a new IP address over DHCP, or renew DHCP lease time.
* Most other subnets are able to obtain / renew IP addresses over DHCP without any problem.
* Kernel debug (`fw ctl debug -m fw + drop`) shows that the reply packets from the DHCP Server are dropped:
`fw_log_drop: Packet proto=17 `*IP_Addres_of_DHCP_Server* `:67 -> `*IP_Addres_of_VSX*`:67 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;`
**Cause:**
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).
**Solution:**
If you do not wish to install a hotfix, the following **workaround** is available - exclude UDP port 68 and UDP port 67 from ClusterXL NAT.
This workaround can be implemented in **two ways** (apply only one of these procedures - if one procedure does not solve the issue, then try the other procedure):
* **Create a manual NAT rule in SmartDashboard to override ClusterXL NAT** - allows a better control over specific cluster
Add the following manual NAT rule for each problematic DHCP Relay agent:
|----|------------------------|------------------------|---------|--------------|--------------------------------|--------------|----------------|
| No | ORIGINAL PACKET ||| TRANSLATED PACKET ||| INSTALL ON |
| No | SOURCE | DESTINATION | SERVICE | SOURCE | DESTINATION | SERVICE | INSTALL ON |
| 1 | DHCP Server IP address | DHCP Relay VIP address | `bootp` | `= Original` | DHCP Relay physical IP address | `= Original` | Cluster_object |
* **Exclude DHCP ports (UDP port 68 and UDP port 67) from ClusterXL NAT** - applies to all managed clusters
Refer to [sk31832 (How to prevent ClusterXL / VRRP / IPSO IP Clustering from hiding its own traffic behind Virtual IP address)](http://supportcontent.checkpoint.com/solutions?id=sk31832) for instructions and location of the relevant '`table.def`' file.
The UDP port 68 and UDP port 67 should be added at the end of these lines in the relevant '`table.def`' file:
`no_hide_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17>, `**<68,17>, <67,17>**` };`
`no_fold_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17>, `**<68,17>, <67,17>**` };`
### Important Notes {#Important Notes}
DHCP connections will **not** survive failover because the connection will be matched on physical IP address of former Active member and DHCP Reply will fail.
**Applies To:**01173615 , 00264391 , 00264365 , 01189061 , 00264717 , 00264387 , 01179741, 01191703 , 01208424 , 01194956 , 01223321 , 01193582 , 01212811 , 01199213 , 01194856, 01191705 , 01201265 , 01208414 , 01194857 , 01223325 , 00264479 , 01193584 , 01212812 , 01194954
*** ** * ** ***
Scenario 4 {#Scenario 4}
------------------------
**Title: *ClusterXL configured as DHCP Relay drops DHCP reply packets sent from DHCP Server***
**Symptoms:**
* ClusterXL configured as DHCP Relay drops DHCP reply packets sent from DHCP Server.
* Kernel debug on cluster members (`fw ctl debug -m fw + drop`) shows:
`fw_log_drop: Packet proto=17 `*IP_Address_of_DHCP_Server* `:67 -> `*IP_Address_of_Host*`:67 dropped by fw_conn_inspect Reason: post lookup verification failed`
**Solution:**
To resolve the problem:
1. Edit the relevant *table.def* file on the Security Management Server - refer to [sk98339 (Location of 'table.def' files on Management Server)](http://supportcontent.checkpoint.com/solutions?id=sk98339):
1. Remove UDP port 67 and UDP port 68 from the *no_fold_services_ports* and from the *no_hide_services_ports* definitions.
2. Save the *table.def* file.
3. Install the Security policy.
4. If the issue remains, try clearing the Connections Table:
**Note:** This operation will delete ALL current connections.
**`[Expert@HostName]# fw tab -t connections -x -y`**
[](http://www.checkpoint.com/services/contact/index.html)
**Applies To:** 00938860, 00264833, 01112639, 00264825, 01234022, 01005777, 01163971, 01244065, 01176689, 01255768, 01153006, 01170333, 00260713, 01101655, 01311100, 01192029, 01173615, 00264365, 00264387, 00264391, 01189061, 01295723, 01233974, 00264717, 01179741
*** ** * ** ***
Scenario 5 {#Scenario 5}
------------------------
**Title: *How to change the value of 'Max Hopcount' for DHCP Relay on Gaia OS***
**Symptoms:**
* Number of hops for Check Point Security Gateway and DHCP Server cannot be configured in Clish, or in Gaia Portal
**Solution:**
If the DHCP Server is located more than 4 hops away from Check Point Security Gateway, then change the value of '`Max Hopcount`' from default 4 hops to the required value (maximal allowed number of hops is 255):
1. Connect to CLI on Security Gateway (over SSH, or console).
2. Go from Clish to Expert mode:
**`HostName> expert`**
3. Change the current DHCP Relay configuration by running the following two commands:
**`[Expert@HostName]# dbset routed:instance:default:bootpgw:interface:`*NAME_OF_CONFIGURED_INTERFACE* `:maxhopcount `*REQUIRED_NUMBER_OF_HOPS***
**`[Expert@HostName]# dbset :save`** *Example - interface eth0 was configured for DHCP Relay, and the DHCP Server is located 8 hops away* :
> `[Expert@HostName]# dbset routed:instance:default:bootpgw:interface:eth0:maxhopcount 8`
> `[Expert@HostName]# dbset :save`
4. Restart the routing daemon '`routed`':
**`[Expert@HostName]# tellpm process:routed`**
**`[Expert@HostName]# tellpm process:routed t`**
5. Check that the routing daemon '`routed`' is running:
**`[Expert@HostName]# ps auxw | grep -v grep | grep '/bin/routed'`**
**Related solutions:**
* [sk72201 (RouteD daemon is down unless default route is configured on Gaia OS)](http://supportcontent.checkpoint.com/solutions?id=sk72201)
* [sk92770 (How to use dbget and dbset on Gaia OS)](http://supportcontent.checkpoint.com/solutions?id=sk92770)
*** ** * ** ***
Scenario 6 {#Scenario 6}
------------------------
**Title: *'Connection contains real IP of NATed address' log for dropped 'DHCP Offer' packets when host tries to get IP address via DHCP***
**Symptoms:**
* NAT does not work properly after ISP failover - when trying to get IP address from DHCP server, it is dropped on "message_info: Connection contains real IP of NATed address"
**Cause:**
On Gaia cluster (in this case VRRP), DHCP Relay packets are supposed to be sent with the inbound interface address, but if NAT is applied, the source interface could be changed, and the returned packet will be dropped by the Security Gateway.
**Solution:**
1. Close all SmartConsole windows.
2. Connect to the CLI on the Security Management Server.
3. Edit the relevant "**`table.def`** " file - refer to [sk98339 (Location of 'table.def' files on Management Server)](http://supportcontent.checkpoint.com/solutions?id=sk98339).
Add the DHCP Relay services to the '`no_hide_services_ports`' table:
`no_hide_services_ports = { <68,17>, <67,17> }; `
4. Install the policy onto onto problematic cluster(s).
5. If the problem persists after the policy install, use one of the following options to clear the connections table on the primary cluster member:
* **Option 1** : Create a temporary SAM rule controlled through SmartView Tracker (Tools -\> Block Intruder) or SmartView Monitor (Tools -\> Suspicious Activity Rules). Once the connection has cleared from the connections table, clear the associated SAM rule in SmartView Tracker (Tools -\> Clear Block) or SmartView Montior (Tools -\> Suspicious Activity Rules -\> Highlight rule and "Remove".
* **Option 2** : Clear the entire connections table with the following command:
`fw tab -t connections -x`
**\*This will cause a noticeable temporary loss of traffic, however will ensure the new change takes immediate effect.**
*** ** * ** ***
Scenario 7 {#Scenario 7}
------------------------
**Title: *DHCP Relay does not work because NAT of DHCP Relay payload was enabled***
**Symptoms:**
* DHCP Relay does not work.
* NAT debug ('`fw ctl debug -m fw + conn nat xlate xltrc`') shows:
(Note: This is an example from a cluster).
```
[-- Stateful VM outbound: Entering (...) --];
;Before VM: 255.255.255.255:68 IPP 17> (len=...) (ifn=N) (first seen) (looked up) ;
... ...
;fw_conn_inspect: Packet accepted (fast path);
;fw_conn_post_inspect: Packet accepted (fast path);
;fw_filter_chain: Final switch, action=ACCEPT;
;fwx_get_xlbuf: SRV xlation buffer found for request: vmside=1, cli->srv(1);
;fwx_get_xldata: got (HOST_IP_ADRESS,0,0.0.0.0,0 : 0) flags = 20, cli->serv (1);
;fw_xlate_packet: connection 255.255.255.255:68 IPP 17>, OUTBOUND(1);
;fw_xlate: changing 255.255.255.255:68 IPP 17> to 255.255.255.255:68 IPP 17>;
;fwx_handle_dhcp_relay_payload: called for conn dir 1, GW_IP_ADRESS:67 -> 255.255.255.255:68 IPP 17;
;fwx_handle_dhcp_relay_payload: Interface id N found for src ip addr GW_IP_ADRESS;
;fwxlate_cluster_ip_by_ifn: ifn is N, clus IP is HOST_IP_ADRESS;
;fwx_handle_dhcp_relay_payload: couldn't get cluster ip for ifn N;
;fwx_handle_dhcp_relay_payload: Will modify giaddr for Splat OS .. GW_IP_ADRESS_in_HEX to HOST_IP_ADRESS_in_HEX;
;fwx_handle_dhcp_relay_payload: giaddr is GW_IP_ADRESS_in_HEX, giaddr_xh is HOST_IP_ADRESS_in_HEX, transaction id is .;
;fwx_handle_dhcp_relay_payload: client to server;
;fwx_handle_dhcp_relay_payload: could not find interface with ip GW_IP_ADRESS_in_HEX_Host_Byte_order;
;fw_filter_chain: OUTBOUND address translation failed;
;After VM: 255.255.255.255:68 IPP 17> (len=...) ;
;VM Final action=DROP;
; ----- Stateful VM outbound Completed -----
```
**Cause:**
NAT of DHCP Relay payload is enabled (default) - value of kernel parameter '`fwx_dhcp_relay_nat`' is set to 1 (one).
**Solution:**
Disable NAT of DHCP Relay payload on Security Gateway / each cluster member - set the value of kernel parameter '`fwx_dhcp_relay_nat`' to 0 (zero):
1. Connect to command line on Security Gateway / each cluster member (over SSH, or console).
2. Log in to Expert mode.
3. Set the value of kernel parameter '`fwx_dhcp_relay_nat`' to 0:
* To check the current value of a kernel parameter:
**`[Expert@HostName]# fw ctl get int fwx_dhcp_relay_nat`**
* To set the desired value for a kernel parameter *on-the-fly*:
**`[Expert@HostName]# fw ctl set int fwx_dhcp_relay_nat 0`**
* To set the desired value for a kernel parameter *permanently*:
Follow [sk26202 (Changing the kernel global parameters for Check Point Security Gateway)](http://supportcontent.checkpoint.com/solutions?id=sk26202). For Gaia / SecurePlatform OS:
> 1. Create the `$FWDIR/boot/modules/fwkern.conf` file (if it does not already exit):
>
> **`[Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf`**
>
> 2. Edit the `$FWDIR/boot/modules/fwkern.conf` file in Vi editor:
>
> **`[Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf`**
>
> 3. Add the following line (spaces are not allowed):
>
> **`fwx_dhcp_relay_nat=0`**
>
> 4. Save the changes and exit from Vi editor.
>
> 5. Check the contents of the `$FWDIR/boot/modules/fwkern.conf` file:
>
> **`[Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf`**
>
> 6. Reboot the Security Gateway / each cluster member.
*** ** * ** ***
Scenario 8 {#Scenario 8}
------------------------
**Title: *DHCP-Relay does not work - Gateway seems to be sending ARP requests using incorrect interface***
**Symptoms:**
* DHCP requests can be seen arriving on the incoming interface. fw monitor also shows that they hit the outgoing interface, but they never seem to be leaving the outgoing interface. They also never arrive at the dhcp-server.
* ARP requests are sent using IP of the incoming interface (client side interface).
* If the router address in the outgoing network is pinged, the connection starts working again as long as the router MAC address stays in the ARP table.
**Cause:**
ARP messages are local to the link. Host on the link ignores messages, as they seem to be arriving from a different network. Pinging the host populates the ARP table, as the echo-requests are sent from the interface in the same network. The connection works until ARP table is cleared again after ARP timeout.
**Solution:**
1. On Security Gateway, enter Expert mode.
2. Run the following command, where \[int\] is the outgoing interface name:
*echo 2 \> /proc/sys/net/ipv4/conf/\[int\]/arp_announce*
3. To make the setting survive reboot, add the following line to */etc/sysctl.conf* using, for example, Vi editor:
*net.ipv4.conf.all.arp_announce=2*
4. Run *sysctl -p*and see if it resolves the issue.
5. If it does, also add to *sysctl.conf* and reboot.
6. If the particular *sysctl* value requires reloading *sysctl.conf* and cannot be made just by setting the value on the live system, then edit *sysctl.conf*and reboot, as the alternative.
*** ** * ** ***
Scenario 9 {#Scenario 9}
------------------------
**Title: *DHCP Relay stopped working after VLAN interfaces were deleted***
**Symptoms:**
* DHCP Relay stops working after VLAN interfaces were deleted.
* DHCP Relay packets are leaving with the Relay Agent IP being 0.0.0.0
* VLAN interfaces were deleted/removed from the OS level.
**Cause:**
The DHCP Relay configuration still refers to the VLAN interfaces that were removed. If DHCP Relay is configured with VLAN interfaces and if the IP addresses on VLAN interfaces are removed, then DHCP Relay must be reconfigured to remove the VLANs in question. This is also true for physical interfaces and for cases where the VLANs are totally deleted, not just the IP addresses.
**Solution:**
Reconfigure DHCP Relay and remove the deleted VLAN interface references.
*** ** * ** ***
Scenario 10 {#Scenario 10}
--------------------------
**Title: *routed on Gaia does not forward BOOTP DHCP Relay packets smaller than 300 bytes***
**Symptoms:**
* routed on Gaia does not forward BOOTP DHCP Relay packets smaller than 300 bytes.
* "fw routed\[2190\]: bootpgw_recv: Accepting runt packet: src IP: 0.0.0.0, dest IP: 255.255.255.255, recv interface: Mgmt recv size: 260, size expected: 300" message in /var/log/messages file.
**Cause:**
As per [RFC 951](http://tools.ietf.org/html/rfc951) minimum BOOTP frame is 300 bytes in length. The Gaia BOOTP relay agent is RFC compliant, and therefore will not forward frames of less than 300 bytes.
Based on these error messages being flooded to the /var/log/messages file: "bootpgw_recv: Accepting runt packet: src IP: 0.0.0.0, dest IP: 255.255.255.255, recv interface: *IF_NAME* recv size: *X*, size expected: 300", this is exactly what is occurring here. The issue is not with the routing daemon or the Security Gateway, the issue is with the traffic.
**Solution:**
This is **not** a Check Point issue.
Find out why the message length is less than 300 bytes from the source to solve this and these messages will stop.
If you want to stop this message to appear, [contact Check Point Support](http://www.checkpoint.com/services/contact/index.html) to get a Hotfix for this issue. A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.
Hotfix adds support to relay BOOTP/DHCP packets as small as 244 bytes.
**Applies To:** 00487728 , 01052121 , 00262480 , 00262480 , 01062874 , 01158120, 00264954
*** ** * ** ***
Scenario 11 {#Scenario 11}
--------------------------
**Title: *Configuring DHCP Relay on VSX via 'sysconfig' command stops DHCP Relay on other Virtual Systems***
**Symptoms:**
* Configuring DHCP Relay on VSX via 'sysconfig' command under 'DHCP Relay Configuration' menu.
* Pressing 'y' at:
`Do you want to restart DHCP Relay daemon in order the changes to take place? (y/n) [y]:`
* DHCP Relay is stopped on other Virtual Systems, but works on the Virtual System, which was just configured.
**Cause:**
Restarting DHCP Relay daemon kills all the 'dhcrepay' processes for all Virtual Systems, and restarts it only for the Virtual System that was just configured.
**Solution:**
[](http://www.checkpoint.com/services/contact/index.html)It is possible to start the DHCP Relay process on the specific Virtual System:
```
# /usr/sbin/dhcrelay.VSID -p 67 -i -i --vrf VSID
```
For example, for Virtual System with VSID 1, with DHCP Relay between the interfaces eth7.111 and eth7.113,
and the DHCP Server at IP 192.168.113.250, we run this command:
```
# /usr/sbin/dhcrelay.1 -p 67 -i eth7.111 -i eth7.113 --vrf 1 192.168.113.250
```
*** ** * ** ***
Scenario 12 {#Scenario 12}
--------------------------
**Title: *ClusterXL configured as DHCP Server drops DHCP Request packets with "Connection contains real IP of NATed address" log***
**Symptoms:**
* Kernel debug (-m fw + drop) shows the drop reason:
*"fw_log_drop_ex: Packet proto=17 DHCP_Relay_IP:67 -\> Cluster_Member_IP:67 dropped by fw_conn_inspect Reason: post lookup verification failed;"*
* Hosts are not assigned with IP addresses
* The DHCP Relay is configured with the Cluster VIP address as the DHCP server.
**Cause**:
The "*dhcp-server-identifier* " option in the "Offer" packet holds the value of the Active cluster member real IP (not VIP). Devices which enforce DHCP RFC will continue sending the DHCP "Request" to destination IP as appears in the "*dhcp-server-identifier* " options field.
In this configuration, the flow will start with the cluster VIP address and the "Request" packet will be dropped as it is being sent to the active cluster member real IP address.
**Solution:**
The DHCP Relay should be configured to relay the packet to the cluster members real IP.
In this case, the packet will be sent to both members and only the Active member will reply.
*** ** * ** ***
Scenario 13 {#Scenario 13}
--------------------------
**Title *DHCP Discover packets are not relayed to DHCP Server***
**Symptoms:**
* Hosts are not able to obtain IP address from DHCP Server through Security Gateway defined as DHCP Relay.
* Traffic capture in FW Monitor on Security Gateway shows that DHCP Discover packets from Hosts pass through both Pre-Inbound ("i") chain and Post-Inbound ("I") chains.
However, these DHCP Discover packets are not relayed to DHCP Server.
* RouteD traces for BOOTP show:
```
BOOTPGW RECV 0.0.0.0+68 -> 255.255.255.255 interface Name_of_Interface cmd Request, length ...
bootpgw_relay_request: dropped request from interface Name_of_Interface, secs(XXX) < waittime(YYY)
task_process_sockets: recv ready for BOOTPGW.0.0.0.0+67
task_receive_packet: task BOOTPGW.0.0.0.0+67 from 0.0.0.0+68 to 255.255.255.255 socket 22 length ...
```
**Cause**:
DHCP Discover packet sent by a Host contains the number of seconds elapsed since the Host started the DHCP cycle. For the initial message, the number of seconds is 0 (zero).
DHCP Relay mechanism compares the "seconds" field in the received DHCP Discover packet to the configured "wait-time" value. If value of "seconds" is less than value of "wait-time", then the DHCP Discover packet is ignored (as seen in the trace output).
The purpose of this behavior is to handle the situation, where there is also a DHCP Server on the local network (or there is another DHCP Relay). The non-zero "wait-time" gives the other DHCP Server / DHCP Relay a chance to respond to the DHCP message before the backup DHCP Relay sends it elsewhere to be handled.
**Solution:**
Follow these steps:
1. Connect to command line on the involved Security Gateway that is defined as DHCP Relay.
2. Log in to Clish.
3. Change the "wait-time" to "default" value:
***HostName\> set bootp interface \ primary wait-time default***
***HostName\> save config***
*** ** * ** ***
Scenario 14 {#Scenario 14}
--------------------------
**Title *DHCP Relay does not work after changing interface configuration***
**Symptoms:**
* *bootp* was correctly configured to use *bond1*
* Topology was correctly updated.
* *bond1*was configured as a clustered interface.
* Policy push succeeded with no errors or warnings.
* Management interface was incorrectly still set as eth1, and eth1 had no IP address because it was moved to *bond1*
* *bond1*did not receive its virtual IP after policy push.
**Cause**:
After enabling tracing in clish: *set trace bootp all on* , in */var/log/routed*, see the following:
```
Dec 3 16:14:33.623208 bootpgw: Relay agent configured in a cluster but Primary Address not configured.get the cluster ip for bond1
Dec 3 16:14:33.623208 bootpgw: cluster ip not found. Relay Agent disabled
```
**Solution:**
**Environment:**
1. Configure eth5 with an IP address.
2. Configure the Management interface to be eth5.
3. Configure DHCP relay on eth5 and a DHCP server that will be located on eth1 on other segment.
4. Test that a client gets IP address from the DHCP.
5. Move the network from eth5 to bond1 whose members are eth5 \& eth2 (this included removing the IP from eth5).
6. Then configure the topology of the gateway and push policy.
7. At this point, client no longer gets IP address from the DHCP server.
1. See in tcpdump on eth5 interface that the broadcast is received by the gateway.
2. See in tcpdump on eth2 interface that no DHCP unicast are send to the DHCP server from the gateway.
8. After reboot, the gateway went up with "default filter" and after *cpstart*returns only "power on self test...". Conclude that the interface pointed to by the management interface setting does not have an IP address.
Follow these steps:
1. Run *set management interface bond1* , then *save config* on both cluster members.
2. Run *cpstop* and *cpstart*
DHCP relay starts working again.
*** ** * ** ***
Scenario 15 {#Scenario 15}
--------------------------
**Title *DHCP Relay does not work in ClusterXL on one or more interfaces***
**Symptoms:**
* DHCP Relay is not working on one or more interfaces.
* */var/log/routed.log* file shows:
`bootpgw: Relay agent configured in a cluster but Primary Address not configured.get the cluster ip for `*Name_of_Interface*
` bootpgw: cluster ip not found. Relay Agent disabled`
* Output of Clish command "*show bootp interface Name_of_Interface* " shows "`NoOut,NoIn`".
*Example* :
```
Interface XXX
Flags: NoOut,NoIn
Max Hopcount: 4
Wait Time: 0
Primary Address: 1.1.1.1
Gateway Address:
Relay To: 1.1.1.2
```
**Cause**:
RouteD daemon can not find the matched cluster interface.
**Solution:**
Enable the Routing Option "Wait for Clustering" as described in [sk92322 - Neighborship for OSPF, BGP, RIP, and PIM in Gaia Cluster is formed with Physical IP addresses upon a reboot](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92322).
*** ** * ** ***
Scenario 16 {#Scenario 16}
--------------------------
**Title *After upgrade, cannot use DHCP relay***
**Symptoms:**
* After upgrade, cannot use DHCP relay.
* Rejecting the connection and drops:
`; 4Dec2018 11:49:12.119818;[cpu_1];[fw4_2];ld2_get_wto_ttl_aggr: d=7998 lp=cphwd_pslglue_conn_db tuple=< ac1c0101,43,a640a01,43,11 >;`
`; 4Dec2018 11:49:12.119819;[cpu_1];[fw4_2];ld_get: h_lookup(ac1c0101,5)=0000000000000000;`
`; 4Dec2018 11:49:12.119821;[cpu_1];[fw4_2];ld2_get_wto_ttl_aggr: not found;`
`; 4Dec2018 11:49:12.119839;[cpu_1];[fw4_2];1543924152:`
`{connection} [ERROR]: up_manager_cmi_handler_match_cb: connection not found; ; 4Dec2018 11:49:12.119844;[cpu_1];[fw4_2];1543924152:{connection}`
`[ERROR]: up_manager_cmi_handler_match_cb: rc FALSE - rejecting conn [172.28.1.1:67 - > 10.100.10.1:67, IPP 17];`
`; 4Dec2018 11:49:12.119973;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=17 172.28.1.1:67 - > 10.100.10.1:67 dropped by fwpslglue_chain Reason: PSL Drop: ASPII_MT`
**Solution:**
This problem was fixed. The fix is included starting from:
* [Check Point R80.40](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk160736)
Check Point recommends to always upgrade to the most recent version
Applies To: PRHF-5333 , PMTR-33993
---
# Agent Instructions
This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.
## Navigating This Knowledge Base
- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content