How to Configure Cobbler as a Proxy DHCP/PXE Server Without Modifying Existing DHCP Infrastructure


2 views

In enterprise environments, modifying the central DHCP server often requires going through bureaucratic processes or isn't permitted due to security policies. Traditional PXE boot setups require DHCP options 66 (next-server) and 67 (bootfile-name) to be configured, but what if you can't touch the existing DHCP infrastructure?

The solution lies in implementing a Proxy DHCP server - a secondary DHCP service that only responds to PXE-specific requests while leaving IP address assignment to the existing DHCP server. Here's how it works:

  • The PXE client broadcasts a DHCP request
  • Both DHCP servers receive the request
  • Main DHCP server responds with IP configuration
  • Proxy DHCP server responds with PXE boot information

Cobbler can leverage dnsmasq (version 2.4.8+) as a proxy DHCP server. Here's a tested configuration:


# /etc/cobbler/dnsmasq.template
# Proxy DHCP configuration (no IP assignment)
dhcp-range=10.10.0.0,proxy
dhcp-ignore=#known
pxe-service=x86PC,"Cobbler PXE Boot",pxelinux,$next_server

The crucial parts of this setup:


# Proxy-only mode (no IP assignments)
dhcp-range=your_network,proxy

# Only respond to known clients (defined in /etc/ethers)
dhcp-ignore=#known

# PXE service definition
pxe-service=x86PC,"PXE Boot Menu",pxelinux,$next_server

For security, you'll want to restrict which machines can boot via PXE. Two approaches:


# Method 1: /etc/ethers file
00:11:22:33:44:55    host1
00:11:22:33:44:56    host2

# Method 2: Cobbler system definitions
cobbler system add --name=host1 --mac=00:11:22:33:44:55 --profile=pxeprofile

Your network layout should account for:

  • Separate VLAN for PXE booting (recommended)
  • Firewall rules allowing DHCP (67/68) and TFTP (69) traffic
  • Proper IP helpers if crossing VLAN boundaries

Common issues and solutions:


# Verify PXE packets are being received
tcpdump -i eth0 -vvv port bootpc or port bootps

# Check dnsmasq logs
tail -f /var/log/daemon.log | grep dnsmasq

# Test TFTP transfer manually
tftp $server
get pxelinux.0

If dnsmasq isn't an option, consider:

  • ISC DHCP in proxy mode (complex configuration)
  • Standalone pxeserver (older project)
  • IPXE with HTTP boot (bypasses DHCP options)

For large deployments:


# Limit DHCP offer rate
dhcp-ratelimit=100

# Configure TFTP block size
tftp-blksize=1468

# Enable parallel downloads
enable-tftp=concurrent

Many enterprise environments have strict network policies that prevent modification of the primary DHCP server. This creates a significant hurdle for system administrators who need to implement PXE booting for automated installations. The traditional approach requires adding PXE-specific options (like next-server and filename) to the main DHCP configuration, which may not be feasible in locked-down environments.

Proxy DHCP (sometimes called PXE server) is a standards-compliant alternative that addresses this exact scenario. As defined in RFC 4578, a Proxy DHCP server can provide just the PXE boot information while the main DHCP server handles IP address assignment. This separation of concerns allows for PXE booting without modifying the existing DHCP infrastructure.

# Typical PXE boot sequence with Proxy DHCP
1. Client broadcasts DHCP Discover
2. Main DHCP server responds with IP offer (no PXE info)
3. Proxy DHCP server responds with PXE boot information
4. Client contacts TFTP server specified in Proxy DHCP response

The breakthrough came with dnsmasq 2.4.8+, which added native Proxy DHCP support. Here's how to configure Cobbler to work in this mode:

# /etc/cobbler/dnsmasq.template
# Cobbler generated configuration file for dnsmasq

# Proxy DHCP configuration
dhcp-range=10.10.0.0,proxy
dhcp-ignore=#known

# Network specifics
expand-hosts
domain=example.com,10.10.15.0

# PXE Service Definition
pxe-service=x86PC, "Cobbler PXE Boot", pxelinux,$next_server

$insert_cobbler_system_definitions

Several important considerations emerged during implementation:

  • The dhcp-range=...,proxy directive tells dnsmasq to operate in Proxy DHCP mode
  • dhcp-ignore=#known restricts responses to clients in /etc/ethers (for security)
  • You must ensure network switches are configured to forward DHCP broadcasts
  • Firewall rules must permit UDP ports 67 (DHCP) and 4011 (Proxy DHCP)

Here's a complete working example from a production environment:

# /etc/cobbler/settings
manage_dnsmasq: 1
next_server: 192.168.1.100
server: 192.168.1.100

# /etc/dnsmasq.conf (standalone proxy mode)
interface=eth1
bind-interfaces
dhcp-range=192.168.1.0,proxy
dhcp-boot=pxelinux.0
pxe-service=x86PC,"PXELinux (Cobbler)",pxelinux
enable-tftp
tftp-root=/var/lib/tftpboot

When implementing this solution, watch for these potential problems:

  • Ensure dnsmasq version is 2.4.8 or higher (dnsmasq -v)
  • Verify TFTP server accessibility (tftp localhost -c get pxelinux.0)
  • Check that both DHCP and Proxy DHCP responses reach the client (use tcpdump)
  • Confirm PXE ROM version supports Proxy DHCP (some older implementations don't)

While dnsmasq works well with Cobbler, other Proxy DHCP options exist:

  • ISC dhcpd with allow booting; and allow bootp; directives
  • Specialized PXE proxies like pxelinux's built-in proxy mode
  • Network device-based solutions (some switches/routers can inject PXE options)