3.2 DHCP Server, DHCP Relay & PPPoE

3.2 DHCP Server, DHCP Relay & PPPoE

Quick Answer: Firebox interfaces in Mixed Routing mode support three local address modes: Use DHCP Server, Use DHCP Relay, or Do Not Use DHCP. The built-in DHCP server provides dynamic IP pools, configurable lease times (default 8 hours), standard network options (DNS, WINS, NTP, gateway), and advanced custom options like Option 43 (vendor-specific discovery) and Options 66/67 (VoIP/PXE provisioning). Fixed IP assignment uses MAC reservations with optional Static ARP to prevent IP spoofing. For multi-subnet enterprise networks, DHCP Relay intercepts client broadcasts (UDP 67) and unicasts them to a central DHCP server by populating the GIADDR field. On External broadband connections, PPPoE encapsulates PPP in Ethernet frames, requiring PAP/CHAP authentication and mandatory MTU clamping to 1492 bytes (TCP MSS to 1452 bytes) to prevent packet fragmentation.

Local Address Assignment in Fireware OS

When a Firebox operates in Mixed Routing mode, each internal interface—whether designated as Trusted, Optional, or Custom—serves as the default gateway for its respective broadcast domain. To manage client address assignment on these connected segments, Fireware provides three mutually exclusive DHCP operational modes on a per-interface basis:

1. Do Not Use DHCP: The Firebox performs no DHCP services on this interface. Connected clients must be statically configured with an IP address, subnet mask, gateway, and DNS servers, or an external DHCP server must reside on the same physical Layer 2 broadcast domain.
2. Use DHCP Server: The Firebox acts as an authoritative DHCP server for the interface subnet, dynamically distributing IP addresses, lease times, and network configuration options directly to requesting clients.
3. Use DHCP Relay: The Firebox functions as an RFC 1542 / RFC 2131 compliant DHCP relay agent, intercepting local client DHCP broadcast queries and forwarding them as unicast packets across routed boundaries to one or more enterprise DHCP servers.

---

Built-In DHCP Server Architecture & Options

When Use DHCP Server is enabled on an interface, the administrator configures an address pool, lease parameters, and distributed network options.

Address Pool Management

The DHCP server pool defines the contiguous block of IP addresses that the Firebox dynamically leases to clients:

• The pool range (Start IP to End IP) must reside within the subnet mask of the configured interface IP.
• Multiple non-contiguous pools can be created on a single interface to accommodate segmented dynamic ranges.
• Enterprise Best Practice: Avoid allocating the entire subnet to the DHCP pool. Reserve static ranges at the beginning or end of the subnet for network infrastructure devices, servers, printers, access points, and management controllers (e.g., for interface 192.168.10.1/24, configure the pool from 192.168.10.100 to 192.168.10.254, leaving .2 through .99 for static assignments).

Lease Duration Mechanics

The DHCP lease duration dictates how long a client may legitimately utilize an assigned IP address before requesting a renewal:

• Default Lease Time: 8 hours (28,800 seconds) in Fireware OS.
• High-Density / Guest Environments: In guest Wi-Fi networks, conference facilities, or high-turnover public spaces, short lease times (e.g., 1 to 2 hours) should be configured. This forces rapid reclamation of released IP addresses, preventing DHCP pool exhaustion.
• Stable Corporate Office Environments: In standard corporate office environments with permanent desktop workstations and static staff counts, longer lease times (e.g., 24 to 72 hours) are recommended. Longer leases reduce local network broadcast traffic and minimize DHCP server processing overhead.

Distributed Network Parameters

By default, the Firebox DHCP server automatically supplies the following parameters to clients:

• Subnet Mask: Inherited from the interface configuration.
• Default Gateway: Defaults to the Firebox interface IP address.
• DNS Servers: Can be inherited from the global Network DNS settings or explicitly specified at the interface level.
• Domain Name: DNS search suffix for local name resolution.
• WINS / NTP Servers: Optional NetBIOS and network time protocol server addresses.

Custom DHCP Options

Enterprise environments frequently require specialized DHCP options to automatically provision VoIP phones, access points, and network boot loaders. Fireware allows administrators to configure custom DHCP options using standard RFC numeric codes and specific data types (IP Address, String, Hexadecimal, Array):

---

MAC Address Reservations & Static ARP Security

Administrators often need specific client devices (such as executive workstations, network printers, or internal file servers) to consistently receive the same IP address while retaining centralized DHCP management. Fireware provides MAC Address Reservations under the DHCP server configuration.

Reservation Mechanics

• The administrator binds a target IPv4 address to the client NIC hardware MAC address (formatted as xx:xx:xx:xx:xx:xx).
• The reserved IP address can reside inside the dynamic DHCP address pool or outside the pool, provided it belongs to the interface's subnet.
• When the client broadcasts a DHCPDISCOVER, the Firebox matches the client hardware MAC address in the packet header and immediately responds with a DHCPOFFER containing the pre-assigned IP address.

Reserved DHCP vs. Static ARP

When adding a reserved address in Fireware, the administrator must choose between two operational types:

MAC Address Reservation Options:
  [ ] Reserved DHCP (Standard DHCP lease bound to MAC)
  [ ] Static ARP (DHCP reservation + permanent kernel ARP table lock)

1. Reserved DHCP (Standard): The DHCP server guarantees that the specified IP address will be leased exclusively to the device presenting that MAC address. However, it does not enforce Layer 2 hardware binding. If a rogue user manually configures that IP statically on an unauthorized laptop, the Firebox will still accept and route traffic from the rogue MAC address.
2. Static ARP (Hardware-Enforced Security): Selecting Static ARP creates a permanent, non-aging entry in the Firebox kernel Address Resolution Protocol (ARP) cache, strictly locking that IP address to that specific MAC address. If an attacker or rogue device manually assigns that IP address to an unauthorized NIC, the Firebox detects the MAC mismatch and immediately drops all incoming and outgoing frames from the rogue host. Static ARP provides robust Layer 2 defense against:
   • ARP Poisoning / ARP Cache Spoofing: Attackers cannot trick the Firebox into redirecting traffic through a malicious gateway.
   • IP Address Hijacking: Unauthorized devices cannot claim critical server IP addresses.
   • Man-in-the-Middle (MitM) Attacks: Ensures communication integrity between the Firebox and mission-critical endpoints.

---

DHCP Relay Agent Implementation

In larger enterprise environments, organizations typically centralize IP address management (IPAM) on dedicated enterprise servers, such as Microsoft Windows Server DHCP or Infoblox appliances. Because DHCP client discovery relies on local Layer 2 broadcast frames (255.255.255.255 on UDP port 67), routers and firewalls block these broadcasts at the subnet boundary.

The DHCP Relay Agent solves this challenge by bridging DHCP requests across routed Layer 3 networks.

DHCP Relay Workflow & GIADDR Stamping

When an interface is configured with Use DHCP Relay, the Firebox participates in the DHCP exchange through an RFC-standard process:

1. Client Broadcast: A newly connected client broadcasts a DHCPDISCOVER packet (Source IP: 0.0.0.0, Destination IP: 255.255.255.255, Source Port: UDP 68, Destination Port: UDP 67).
2. Firebox Interception: The Firebox interface intercepts the broadcast UDP 67 frame.
3. GIADDR Header Insertion: The Firebox inspects the packet header and writes its own interface IP address (e.g., 192.168.20.1) into the GIADDR (Gateway IP Address) field. It also increments the Hops counter.
4. Unicast Forwarding: The Firebox converts the broadcast packet into a standard unicast UDP packet (Source IP: 192.168.20.1, Destination IP: 10.0.1.50 [the central Windows DHCP server]) and routes it across the internal network or Branch Office VPN.
5. Server Scope Selection: When the central DHCP server receives the packet, it reads the GIADDR field (192.168.20.1). The server recognizes that the client resides on the 192.168.20.0/24 subnet, matches it against its active DHCP scopes, and selects an available IP address from that specific scope.
6. Unicast DHCPOFFER Return: The DHCP server sends a unicast DHCPOFFER back to the Firebox GIADDR (192.168.20.1) on UDP port 67.
7. Client Delivery: The Firebox receives the DHCPOFFER, matches the client transaction ID, and delivers the offer to the client on UDP port 68 as a local broadcast or unicast frame.
8. The subsequent DHCPREQUEST and DHCPACK cycle traverses the exact same relay path.

Policy Requirement: When DHCP Relay forwards traffic across internal subnets or through a Branch Office VPN tunnel, a firewall policy must allow UDP port 67/68 traffic between the Firebox interface IP and the central DHCP server IP.

---

PPPoE Client Configuration on External Interfaces

Many broadband Internet service providers—particularly fiber-to-the-home (FTTH), DSL, and metro-Ethernet providers—require customer premises equipment (CPE) to establish a Point-to-Point Protocol over Ethernet (PPPoE, RFC 2516) session to authenticate the subscriber and provision the public IP address.

PPPoE Configuration Parameters in Fireware

When an External interface is set to PPPoE in Fireware Web UI or Policy Manager, the administrator must configure:

• User Name & Password: The subscriber credentials supplied by the ISP.
• Service Name (Optional): Used when the ISP operates multiple PPPoE concentrators on a single physical link.
• Authentication Method: Auto, PAP (Password Authentication Protocol - cleartext), or CHAP (Challenge Handshake Authentication Protocol - MD5 hashed challenge-response).
• IP Address Assignment: Obtain an IP address automatically via IPCP (IP Control Protocol), or manually specify a static public IP if assigned by the provider.

The MTU & TCP MSS Clamping Challenge

The fundamental engineering consideration when deploying PPPoE is frame encapsulation overhead and its impact on the Maximum Transmission Unit (MTU):

1. Standard Ethernet MTU: The standard maximum payload size for standard Ethernet frames is 1500 bytes.
2. PPPoE Encapsulation Overhead: Encapsulating PPP within an Ethernet frame adds an 8-byte header (6 bytes for the PPPoE session header + 2 bytes for the PPP Protocol Identifier).
3. Effective PPPoE MTU: Because the physical Ethernet frame cannot exceed 1500 bytes, the maximum IP payload allowed over a PPPoE interface is: $\text{PPPoE MTU} = 1500 - 8 = 1492\text{ bytes}$

Standard Ethernet Frame (MTU 1500):
+---------------------+-------------------------------------------------+
| Ethernet Hdr (14B)  | IP Payload (Up to 1500 Bytes)                   |
+---------------------+-------------------------------------------------+

PPPoE Encapsulated Frame (Physical Max 1500, IP MTU 1492):
+---------------------+-----------------+-------------------------------+
| Ethernet Hdr (14B)  | PPPoE Hdr (8B)  | IP Payload (Max 1492 Bytes)   |
+---------------------+-----------------+-------------------------------+

The "Black Hole" Problem & Path MTU Discovery

Most modern operating systems generate TCP packets designed for a standard 1500-byte MTU, establishing a standard Maximum Segment Size (MSS) of 1460 bytes (1500 bytes minus 20 bytes IPv4 header and 20 bytes TCP header). Furthermore, modern web traffic (HTTPS, cloud applications) sets the Don't Fragment (DF) flag in the IP header.

If a client transmits a 1500-byte packet with DF set toward a Firebox running PPPoE (MTU 1492):

1. The Firebox cannot encapsulate the 1500-byte packet into a 1492-byte PPPoE payload without fragmenting it.
2. Because the DF flag is set, the Firebox is forbidden from fragmenting the packet. It must drop the packet and return an ICMP Type 3 Code 4 message (Destination Unreachable, Fragmentation Needed) to the sending client, instructing it to lower its MTU (Path MTU Discovery / PMTUD).
3. In modern networks, intermediate firewalls and ISPs frequently block ICMP messages for security. As a result, the client never receives the ICMP error message. The client continues retransmitting the oversized packet, while the server waits indefinitely.
4. Symptom: Small packets (DNS queries, ping, initial TCP 3-way handshakes) succeed, but web pages stall, TLS negotiations fail, and file downloads freeze completely. This phenomenon is known as a PMTUD black hole.

The Solution: Automatic TCP MSS Clamping

Fireware OS automatically resolves this issue by enforcing TCP MSS Clamping on PPPoE interfaces:

• The Firebox inspects the TCP 3-way handshake (SYN and SYN-ACK packets) passing through the PPPoE interface.
• It reads the advertised TCP MSS option. If the client advertises an MSS greater than 1452 bytes ($1492 - 20\text{ [IP]} - 20\text{ [TCP]} = 1452$), the Firebox actively rewrites the MSS value in the TCP header to 1452 bytes before transmitting it.
• Both client and server agree to never send segments larger than 1452 bytes. Every packet easily fits within the 1492-byte PPPoE frame, completely eliminating packet drops and fragmentation.

---

Operational Verification & Diagnostic Tools

To verify DHCP and PPPoE operations in Fireware:

• FSM Status Report > DHCP Leases: Displays active IP leases, client MAC addresses, hostnames, lease start times, and expiration timestamps.
• FSM Status Report > ARP Table: Displays resolved IP-to-MAC bindings, highlighting Static entries created by MAC reservations.
• Web UI System Status > DHCP Leases: Provides a searchable table of all active leases across all configured interfaces.
• Fireware CLI Commands:
  • show dhcp lease — Lists all current dynamic and reserved DHCP leases.
  • show arp — Displays the active kernel ARP cache.
  • debug pppoe — Initiates real-time debugging of PPPoE discovery (PADI, PADO, PADR, PADS), LCP negotiation, and PAP/CHAP authentication.