Next Generation Firewalls : Configure DHCP Relay on Gaia OS

(1) Objective

This document describes how to setup DHCP Relay on Check Point Gaia OS.

This document focuses on the basic configuration of DHCP Relay and does not discuss DHCP Relay features in details.

Before starting the ECMP with OSPF configuration, user should be familiar with underlying features and their configurations such as static and dynamic routing, ClusterXL, VRRP, SAM configuration.

It is assumed that user has basic knowledge of routing and DHCP Relay.

(2) Introduction

DHCP
The Dynamic Host Configuration Protocol (DHCP) is a standardized networking protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services. With DHCP, computers request IP addresses and networking parameters automatically from a DHCP server, reducing the need for a network administrator or a user to configure these settings manually.
The Dynamic Host Configuration Protocol is used by computers for requesting Internet Protocol parameters, such as an IP address from a network server. The protocol operates based on the client-server model.
When a computer or other networked device connects to a network, its DHCP client software in the operating system sends a broadcast query requesting necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers. On receiving a request, the server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network, and the time period for which the allocation (lease) is valid. A host typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When an assignment is refreshed by the client computer, it initially requests the same parameter values, but may be assigned a new address from the server, based on the assignment policies set by administrators.
DHCP is used for Internet Protocol version 4 (IPv4), as well as IPv6. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.
DHCP Relay
DHCP Relay extends Dynamic Host Configuration Protocol (DHCP) operation across multiple hops to an outside network. DHCP Relay allows a centrally managed DHCP Server on one LAN to allocate IP addresses to a client on another LAN through a routed network.
In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP Servers. However, DHCP Servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP Server using IP routing, because it does not have a routable IP address, nor does it know the IP address of a router.
In order to allow DHCP clients on subnets not directly served by DHCP Servers to communicate with DHCP Servers, DHCP Relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the DHCP Relay agent receives the broadcast and transmits it to one or more DHCP Servers using unicast. The DHCP Relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP Server uses the GIADDR to determine the subnet, on which the DHCP Relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP Server replies to the client, it sends the reply to the GIADDR address, again using unicast. The DHCP Relay agent then retransmits the response on the local network.
DHCP Relay offers the following advantages over standard BOOTP/DHCP:
- Provides redundancy by configuring an interface on the Check Point Security Gateway to relay client configuration (IP address) requests to multiple DHCP Servers. With this setup, configuration requests are relayed to all the listed servers simultaneously.
- Provides load balancing by configuring multiple interfaces on the Check Point Security Gateway to relay client configuration (IP address) requests to different DHCP Servers.
- Allows to centrally manage client configuration across multiple LANs. This is particularly useful in large enterprise environments.
  When an interface configured for BOOTP/DHCP Relay receives a BOOTP/DHCP Request, it forwards the request to all the DHCP Servers in its server list. It does this after waiting a specified length of time to see if a local DHCP Server answers the BOOTP/DHCP Request.
  If a Primary IP address is specified, it stamps the BOOTP/DHCP Request with that IP address. Otherwise, it stamps the BOOTP/DHCP Request with the lowest numeric IP address specified for the interface.

(3) Configuration

Example topology:

Single Gateway / StandAlone machine as DHCP Relay:
ClusterXL / VRRP cluster as DHCP Relay:

Procedure:

Configure DHCP Relay (either in Gaia Portal, or in Clish):
- Either in Gaia Portal
  1. In the tree view, go to 'Advanced Routing' pane - click on 'DHCP Relay'.
  2. In the 'BOOTP/DHCP' section, Click on 'Add' button:
  3. 'Add BOOTP/DHCP DHCP Relay' window opens:
  4. In the 'Interface' field:
    Select an interface, on which the Security Gateway should listen to BOOTP/DHCP Requests from hosts.
  5. In the 'Primary Address' field:
    BOOTP/DHCP Relay will stamp all BOOTP/DHCP Requests that are forwarded by Security Gateway to DHCP Server with the IP address specified in this field.
    Default:
    - Lowest IP address on the interface (in case multiple IP addresses are assigned to that interface).
    - Gaia OS defines the IP address of the for internal (Client side) interface as 'Primary Address'.
    Notes:
    - On single Security Gateway - enter the primary physical IP address that was configured on the selected interface (this interface is facing the Client's side).
    - On Cluster members - enter the Cluster Virtual IP address that was configured on the selected interface in SmartDashboard in Cluster Topology (VIP address facing the Client's Side).
    Important Notes:
    - Cluster Virtual IP is not accepted correctly in R75.40, R75.40VS, R75.45, and R75.46 versions (this issue was fixed in R76 and above).
      
      For these versions:
      - Either contact Check Point Support to get a Hotfix (for Issue 00938860) to be able to configure Cluster Virtual IP address (as designed).
      - Or configure the physical IP address of the involved cluster interface (there is no negative impact).
  6. In the 'Wait Time' field:
    Note: This setting was used for legacy reasons. Users are not supposed to modify this value anymore.
    Defines amount of time (in seconds) to wait before forwarding a BOOTP/DHCP Request to DHCP Server. Each client-generated BOOTP/DHCP Request includes the elapsed time since the client began the booting process.
    The BOOTP/DHCP Relay does not forward the BOOTP/DHCP Request until the indicated elapsed time is at least the 'Wait Time'.
    This delay provides an opportunity for a local DHCP Server to reply to BOOTP/DHCP Request before attempting to relay the BOOTP/DHCP Request to a remote DHCP Server.
    Default:
    - 0 seconds
    Range:
    - 0 - 65535 seconds
    Notes:
    - For Windows OS clients, set the value to "0" seconds (Explanation: Gaia OS attempts to allow a local BOOTP/DHCP Server (on Client's LAN) to respond to the initial broadcast by waiting to relay the BOOTP/DHCP Request packet until the client increments its Elapsed Time value to "3". Some implementations of DHCP such as on Windows OS, do not increment this value until after an IP address has been leased. As a result, the 'Wait Time' on the Gaia OS must be set to "0" to allow interoperability).
  7. In the 'Maximum Hops' field:
    Defines the maximal number of hops before the BOOTP/DHCP Requests packet is discarded.
    Default:
    - 4 hops
    Range:
    - 1 - 255 hops
    Notes:
    - Set this value at least to the number of hops between the DHCP Server and the Security Gateway that acts as DHCP Relay.
  8. In the 'Relays' section:
    1. Click on 'Add' button.
    2. Enter the IPv4 address of the DHCP Server, to which the Security Gateway will forward (in unicast) the BOOTP/DHCP Requests from hosts.
      Example based on our topology:
      
      Notes:
      - You can configure multiple DHCP Servers independently on each interface:
        
        Configuring different DHCP Servers on different interfaces provides load balancing
        
        Configuring multiple DHCP Servers on a single interface provides redundancy
      - IP address configured for Relay can not belong to Security Gateway.
    3. Click on 'OK' button in 'Add Relay' window.
  9. Click on 'Save' button in 'Add BOOTP/DHCP DHCP Relay' window.
  Example based on our topology:
- Or in Clish
  1. Connect to command line on Security Gateway / each cluster member (over SSH, or console).
  2. Log in to Clish.
  3. Configure an interface, on which the Security Gateway should listen to BOOTP/DHCP Requests from hosts:
    HostName> set bootp interface INTERFACE_NAME on
  4. Configure the 'Primary Address' and 'Wait Time':
    HostName> set bootp interface INTERFACE_NAME primary PRIMARY_IP_ADDRESS wait-timeWAIT_TIME on
    - Explanation for 'Primary Address':
      BOOTP/DHCP Relay will stamp all BOOTP/DHCP Requests that are forwarded by Security Gateway to DHCP Server with the IP address specified in this field.
      Default:
      
      Lowest IP address on the interface (in case multiple IP addresses are assigned to that interface).
      
      Gaia OS defines the IP address of the for internal (Client side) interface as 'Primary Address'.
      
      Notes:
      
      On single Security Gateway - enter the primary physical IP address that was configured on the selected interface.
      
      On Cluster members - enter the Cluster Virtual IP address that was configured on the selected interface in SmartDashboard in Cluster Topology.
      
      Important Notes:
      
      Cluster Virtual IP is not accepted correctly in R75.40, R75.40VS, R75.45, and R75.46 versions (this issue was fixed in R76 and above).
      
      For these versions:
      
      Either contact Check Point Support to get a Hotfix (for Issue 00938860) to be able to configure Cluster Virtual IP address (as designed).
      
      Or configure the physical IP address of the involved cluster interface (there is no negative impact).
    - Explanation for 'Wait Time':
      Note: This setting was used for legacy reasons. Users are not supposed to modify this value anymore.
      Defines amount of time (in seconds) to wait before forwarding a BOOTP/DHCP Request to DHCP Server. Each client-generated BOOTP/DHCP Request includes the elapsed time since the client began the booting process.
      The BOOTP/DHCP Relay does not forward the BOOTP/DHCP Request until the indicated elapsed time is at least the 'Wait Time'.
      This delay provides an opportunity for a local DHCP Server to reply to BOOTP/DHCP Request before attempting to relay the BOOTP/DHCP Request to a remote DHCP Server.
      Default:
      
      0 seconds
      
      Range:
      
      0 - 65535 seconds
      
      Notes:
      
      For Windows OS clients, set the value to "0" seconds (Explanation: Gaia OS attempts to allow a local BOOTP/DHCP Server (on Client's LAN) to respond to the initial broadcast by waiting to relay the BOOTP/DHCP Request packet until the client increments its Elapsed Time value to "3". Some implementations of DHCP such as on Windows OS, do not increment this value until after an IP address has been leased. As a result, the 'Wait Time' on the Gaia OS must be set to "0" to allow interoperability).
  5. Define the maximal number of hops before the BOOTP/DHCP Requests packet is discarded:
    HostName> set bootp interface INTERFACE_NAME maxhopcount NUMBER_OF_HOPS
    Default:
    - 4 hops
    Range:
    - 1 - 255 hops
    Notes:
    - Set this value at least to the number of hops between the DHCP Server and the Security Gateway that acts as DHCP Relay.
  6. Configure the IPv4 address of the DHCP Server, to which the Security Gateway will forward (in unicast) the BOOTP/DHCP Requests from hosts:
    HostName> set bootp interface INTERFACE_NAME relay-to IP_ADDRESS_of_DHCP_SERVER on
    Notes:
    - You can configure multiple DHCP Servers independently on each interface:
      
      Configuring different DHCP Servers on different interfaces provides load balancing
      
      Configuring multiple DHCP Servers on a single interface provides redundancy
    - IP address configured for Relay can not belong to Security Gateway.
  7. Save Gaia configuration:
    HostName> save config
Example based on our topology:
```
HostName> set bootp interface eth1 on
HostName> set bootp interface eth1 relay-to 10.10.1.50 on
HostName> set bootp interface eth1 primary 10.20.1.66 wait-time 0 on
HostName> set bootp interface eth1 maxhopcount 0
HostName> save config
```

On Security Management Server / Multi-Domain Security Management Server
For R77.20, refer to sk98839 (DHCP configuration in R77.20).
Configuration described in this section applies only to the environment R77.10 and lower:

Security Management Server / Multi-Domain Security Management Server is R77.10 and lower
All managed Security Gateways / Clusters are R77.10 and lower

Procedure:

Connect to command line on Security Management Server / Multi-Domain Security Management Server (over SSH, or console).
Log in to Expert mode.

Check the relevant table.def file (refer to sk98339 (Location of 'table.def' files on Management Server)):
The UDP port 68 and UDP port 67 have to be excluded from ClusterXL NAT.
Note: Refer to sk31832 (How to prevent ClusterXL / VRRP / IPSO IP Clustering from hiding its own traffic behind Virtual IP address).
Change from

no_hide_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17> };

no_fold_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17> };

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> };

In SmartDashboard, configure specific security rules using the following legacy services:

Traffic	Service
DHCP Requests from Hosts to DHCP Server	`bootp`
DHCP Replies from DHCP Server to Hosts	`bootp`
DHCP Relay from Security Gateway / Cluster to DHCP Server	`dhcp-relay`
DHCP Requests from Security Gateway / Cluster itself to DHCP Server	`dhcp-req-localmodule`
DHCP Replies from DHCP Server to Security Gateway / Cluster itself	`dhcp-rep-localmodule`

In SmartDashboard, install policy onto involved Security Gateway / Cluster object.
Enable NAT of DHCP Relay payload on the involved Security Gateway / Cluster members using the kernel parameter 'fwx_dhcp_relay_nat':
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 1 (one).
  - 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 1
  - To set the desired value for a kernel parameter permanently (for your operating system):
    Follow sk26202 (Changing the kernel global parameters for Check Point Security Gateway).
    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=1
    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.

(4) Verifying DHCP Relay functionality

Display BOOTP/DHCP Relay configuration:
HostName> show configuration bootp
Display BOOTP/DHCP Relay state for specific interface:
HostName> show bootp interface INTERFACE_NAME
Display BOOTP/DHCP Relay state for all interfaces:
HostName> show bootp interfaces
Display BOOTP/DHCP Relay statistics:
HostName> show bootp stats

(5) Troubleshooting

Contact Check Point Support for any assistance.

Refer to these solutions:

Basic steps:

Check /var/log/messages* files on Security Gateway for any errors related to DHCP Relay.
Check that DHCP Clients are configured for obtaining IP Address automatically from the DHCP Server.
Check that DHCP Server has IP Address pool configured for providing IP addresses to the DHCP Clients.
Check that Security Gateway is able to reach the DHCP Server (relevant route exist on Security Gateway and DHCP Server is physically reachable).

Check that DHCP Clients send BOOTP/DHCP Requests correctly

Capture the traffic on DHCP Clients

Capture the traffic on Security Gateway

Example:

[Expert@GW2:0]# tcpdump -i eth1 'port bootps'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:16:13.657795 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:15:8d:fc (oui Unknown), length: 312
14:16:13.661222 IP 10.20.1.60.bootps > 10.20.1.20.bootpc: BOOTP/DHCP, Reply, length: 300

Check that Security Gateway forwards BOOTP/DHCP Requests correctly to DHCP Server in unicast

Capture the traffic on DHCP Server

Capture the traffic on Security Gateway

Example:

[Expert@GW2:0]# tcpdump -i eth0 'port bootps'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:15:00.221222 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:15:8d:fc (oui Unknown), length: 312
14:15:00.222727 IP 10.20.1.60.bootps > 10.10.1.50.bootps: BOOTP/DHCP, Request from 00:0c:29:15:8d:fc (oui Unknown), length: 312
14:15:00.226799 IP 10.10.1.50.bootps > 10.20.1.60.bootps: BOOTP/DHCP, Reply, length: 300

Check that DHCP Server responds to Security Gateway correctly:

Capture the traffic on DHCP Server

Capture the traffic on Security Gateway

Example:

[Expert@GW2:0]# tcpdump -i eth0 'port bootps'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:15:00.221222 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:15:8d:fc (oui Unknown), length: 312
14:15:00.222727 IP 10.20.1.60.bootps > 10.10.1.50.bootps: BOOTP/DHCP, Request from 00:0c:29:15:8d:fc (oui Unknown), length: 312
14:15:00.226799 IP 10.10.1.50.bootps > 10.20.1.60.bootps: BOOTP/DHCP, Reply, length: 300

Check that Security Gateway forwards the response from DHCRP Server to DHCP Clients correctly:

Capture the traffic on DHCP Clients

Capture the traffic on Security Gateway

Example:

[Expert@GW2:0]# tcpdump -i eth1 'port bootps'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:16:13.657795 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:15:8d:fc (oui Unknown), length: 312
14:16:13.661222 IP 10.20.1.60.bootps > 10.20.1.20.bootpc: BOOTP/DHCP, Reply, length: 300

Check Connections Table on Security Gateway:
[Expert@HostName]# fw tab -t connections -u -f 1>> /var/log/conn_table.txt 2>> /var/log/conn_table.txt [Expert@HostName]# grep -E "SPort: 67|SPort: 68|DPort: 67|DPort: 68" /var/log/conn_table.txt

Example:

15:16:05        172.30.111.80 >    : -----------------------------------(+); Direction: 1; Source: 255.255.255.255; SPort: 68; Dest: 192.168.1.1; DPort: 67; Protocol: udp; CPTFMT_sep_1: ->; Direction_1: 0; Source_1: 192.168.1.1; SPort_1: 67; Dest_1: 255.255.255.255; DPort_1: 68; Protocol_1: udp; FW_symval: 5; product: VPN-1 & FireWall-1; product_family: Network;

Check whether BOOTP/DHCP packets are dropped by Security Gateway:
Prepare

[Expert@HostName]# fw ctl debug 0
[Expert@HostName]# fw ctl debug -buf 32000
[Expert@HostName]# fw ctl debug -m fw + drop

Verify debug buffer and flags

[Expert@HostName]# fw ctl debug -m fw

Start

[Expert@HostName]# fw ctl kdebug -T -f > /var/log/debug.txt

Replicate the issue
Stop

Press CTRL+C
[Expert@HostName]# fw ctl debug 0

Analyze

/var/log/debug.txt

Example:

;[fw4_0];fw_log_drop_ex: Packet proto=17 0.0.0.0:68 -> 255.255.255.255:67 dropped by fw_handle_first_packet Reason: Rulebase drop - rule 1;
;[fw4_0];fw_log_drop_ex: Packet proto=17 0.0.0.0:68 -> 255.255.255.255:67 dropped by fw_handle_first_packet Reason: Rulebase drop - rule 1;

2 comments:

Sancuro4 May 2019 at 02:29
With this blog we come to know about Checkpoint Firewall and its configuration. Sancuro is an online platform that helps businesses to buy online Checkpoint firewall DHCP configuration on https://www.sancuro.com/services/check-point-firewall-dhcp-configuration
Unknown26 February 2021 at 02:19
Next Generation firewalls are used to protect the system from being harmed. These firewalls filter the traffic configured on the system and checks for the faults by monitoring the data and do deep inspection by spotting malware.

Thursday, 22 January 2015

Configure DHCP Relay on Gaia OS

(1) Objective

(2) Introduction

(3) Configuration

(4) Verifying DHCP Relay functionality

(5) Troubleshooting

2 comments: