Skip to content
Avanet

How to set up Sophos Firewall as a DHCP server

Sophos Firewall

Sophos Firewall can distribute IPv4 addresses, the gateway, DNS servers and other network settings directly to clients. To do this, create a server for the client interface under Network > DHCP, define the address range and then check whether the client receives the correct lease.

Quick procedure: Open Network > DHCP > Server > Add, select the interface and address range, select Use interface IP as gateway, choose the DNS settings deliberately and save the configuration. Then check the DHCP server service under System services > Services and verify the assigned address under IPv4 lease.

This guide covers a DHCPv4 server for clients on a directly connected network. If a central DHCP server needs to serve another subnet, see Set up and test DHCP Relay on Sophos Firewall. PXE, VoIP and vendor-specific values are covered in Configure DHCP options on Sophos Firewall.

IPv6 uses different roles for address assignment and the default gateway. The complete procedure is covered in Set up and test a DHCPv6 server on Sophos Firewall.

Example and address planning

The example uses a client VLAN with the following values:

  • Interface: VLAN20 - 10.20.0.1/24
  • Dynamic range: 10.20.0.100 to 10.20.0.199
  • Gateway: 10.20.0.1
  • Static mapping for a printer: 10.20.0.20
  • Internal DNS servers: 10.10.0.10 and 10.10.0.11
  • Domain Name: corp.example

The dynamic range is within the interface network, but doesn’t include the network address, broadcast address or gateway. In this example, the addresses below 10.20.0.100 remain reserved for infrastructure and static mappings. This prevents this DHCP range from also distributing the reserved addresses dynamically. However, this separation doesn’t protect against the same IP address being configured manually on another device.

Before enabling the server, check which addresses are already used by switches, access points, printers or servers. If another DHCP server is still running in the same VLAN, first decide which server will be responsible in future. Two uncoordinated servers can distribute different gateways or DNS servers and cause intermittent symptoms.

The interface itself must already have the correct static IP address. Configure a VLAN interface on Sophos Firewall explains how the interface, zone and VLAN work together.

Configure the DHCP server

  1. Open Network > DHCP.
  2. Under Server, click Add.
  3. Enter a unique name such as dhcp-vlan20-clients.
  4. Under Interface, select the client interface VLAN20 - 10.20.0.1.
  5. Under Dynamic IP lease, add the range 10.20.0.100 to 10.20.0.199.
  6. Enter 255.255.255.0 as the Subnet mask for the example /24 network.
  7. Select Use interface IP as gateway. Clients then receive 10.20.0.1 as their Gateway.
  8. Set the DNS servers, Domain name, and lease times to suit the network.
  9. Add static MAC-to-IP mappings if required.
  10. Click Save.

For directly connected clients, the selected interface determines the network on which the firewall responds to DHCP requests. The dynamic range must therefore match the subnet of this interface. DHCP servers can be configured on physical, VLAN, wireless and bridge interfaces, but not on an Interface Alias. A DHCPv4 server can’t be configured on an interface that is already used for DHCP Relay.

For directly connected clients, leave Accept client request via relay cleared. Enable it only when this server configuration must accept requests from a remote client subnet through a relay agent. Each remote client network needs a matching server configuration with its own gateway; see the DHCP relay guide for the complete configuration.

These server configurations can share the same DHCP interface on which the server receives forwarded requests. Distinguish the listening interface from the remote client subnet: each configuration’s address range, subnet mask and gateway belong to its client network. The server assigns addresses from the subnet of the relay agent’s source address; sharing a listening interface therefore does not replace a separate configuration for each client network.

Choose the gateway and DNS correctly

For a normal client network, the Sophos Firewall IP address on this interface is the gateway. In the example, clients therefore receive 10.20.0.1.

With Use device’s DNS settings, the firewall distributes its configured DNS servers to clients. This is suitable if these servers can resolve both public names and the required internal names. In an AD environment, the internal DNS servers are generally entered so that domain controllers, internal services and search domains work reliably. Public resolvers alone are usually not sufficient.

Domain name supplies a DNS suffix to the network adapter. With corp.example, for example, the client can expand the hostname fileserver to fileserver.corp.example. This replaces neither a DNS record nor a reachable DNS server; test both separately.

If clients receive the firewall IP address as their DNS server, Sophos Firewall can forward requests for specific internal zones to the responsible servers. This scenario is covered in Configure DNS request routes on Sophos Firewall. If DHCP distributes the addresses of other DNS servers directly, however, client requests don’t reach the firewall’s request routes.

The WINS server 1 and WINS server 2 fields are intended only for legacy NetBIOS environments. Leave them empty unless clients or applications still require a WINS service. If WINS remains in use, enter the actual server addresses and test name resolution from an affected client.

Set suitable lease times

Default lease time is the regular lease time issued to the client. Max lease time is the upper limit; once it expires, the client must send a new request to the DHCP server. Both values are specified in minutes.

Longer leases are useful in stable office or device networks because the client population rarely changes. In guest, training or frequently changing wireless networks, a shorter lease prevents disconnected devices from occupying the range for a long time.

However, very short leases generate unnecessary renewals. The deciding factors are therefore the size of the address range and how often the clients change, rather than a single ideal value.

Conflict detection checks an address before assigning it and helps identify IP addresses that are already in use. This feature is particularly useful if the network still contains manually configured devices or an older address plan that hasn’t been fully documented.

Create a static IP-to-MAC mapping

A static mapping ensures that a specific device always receives the same address through DHCP. This is useful for printers, access points or other devices that must remain reachable but should continue to receive centrally configured settings such as the gateway and DNS servers.

Under Static IP MAC mapping, enter the hostname, MAC address and required IP address. In this example, the printer with its actual MAC address always receives 10.20.0.20. This address is deliberately outside the dynamic range.

A DHCP mapping isn’t the same as an IP address configured manually on the device: The device remains a DHCP client, but the firewall reserves the correct lease. If a notebook or smartphone uses a private or randomised wireless MAC address, the mapping must match the MAC address the device actually uses on that wireless network.

A single MAC address can have no more than five static IP addresses, provided they are in different subnets. A normal mapping in one network doesn’t require the global setting.

In SFOS 23, when the same MAC address is bound in multiple DHCP server configurations, set Lease scope for static binding to Global under Network > DHCP > Advanced server settings. Clients can then obtain an address from any DHCP server configured on the firewall, regardless of where the static IP-MAC binding is configured. Network restricts this to the server containing the binding. Record the previous value first, then test each affected scope with a new client lease. For rollback, restore exactly the recorded value.

SFOS 22: global binding through the Device Console

Before changing the global mapping, sign in over SSH and read the current method and scope in the Device Console:

system dhcp conf-generation-method show
system dhcp static-entry-scope show

Then change only values that differ from the required target state:

system dhcp conf-generation-method new
system dhcp static-entry-scope global

The setting applies to all DHCP server configurations. It isn’t required for normal one-off mappings and should therefore be changed only for this multiple-scope scenario.

The documented defaults are old and network. The old generation method can provide incorrect information such as DNS servers or the gateway when MAC addresses are bound more than once. Do not overwrite an already customized state. Rollback uses the exact values read beforehand; only for a confirmed default state are they system dhcp static-entry-scope network and system dhcp conf-generation-method old. Afterwards, test every affected scope with a new client lease.

Check the service and test the lease

After saving the configuration, check under System services > Services that DHCP server is running. If the service is stopped, start it there.

⚠️ In an HA cluster, Sophos supports the DHCP service in Active-passive mode, not Active-active mode. Confirm this limitation before rollout; changing the HA mode is not a troubleshooting step for an individual scope.

Then connect a controlled test client to the correct VLAN. On Windows, request and check a new lease as follows:

ipconfig /release
ipconfig /renew
ipconfig /all

⚠️ ipconfig /release disconnects the current IPv4 connection. Don’t run the command over that same remote connection unless an alternative means of access is available.

The client should receive an address from 10.20.0.100 to 10.20.0.199, the gateway 10.20.0.1 and the intended DNS servers. Under Network > DHCP > IPv4 lease, the firewall shows the assigned address with its start and end time, MAC address and hostname.

At a minimum, the following checks should succeed:

  1. The client receives an address from the correct range.
  2. The gateway and DNS servers match the plan.
  3. The gateway is reachable.
  4. Internal and external names are resolved.
  5. The client can reach only the networks and services permitted by its firewall rule.

No address or an incorrect address received

If the client doesn’t receive a lease, first check the interface, VLAN and service status. The following issues are particularly common:

  • Incorrect interface: The DHCP server isn’t assigned to the interface for the client network.
  • VLAN doesn’t reach the firewall: The switch uplink doesn’t permit the tagged VLAN, or the client port is assigned incorrectly.
  • Address range doesn’t match: The start or end address is outside the interface subnet.
  • Range is exhausted: Compare the number and duration of occupied leases with the size of the configured range. The lease list shows assigned addresses, but doesn’t provide a separate list of free addresses.
  • Another DHCP server responds: The client receives an address but the wrong gateway or DNS servers.
  • Policy rule denied for source 0.0.0.0: If neither a DHCP server nor a relay is configured on the interface, a client request may be dropped with this entry. The message therefore doesn’t prove that a normal firewall rule is the cause. Check the DHCP server, relay and interface assignment first.
  • DHCP Relay is required: The client isn’t on the directly connected network of the server.
  • Static mapping doesn’t apply: The MAC address entered doesn’t match the MAC address the client actually uses.

A packet capture filtered on port 67 or port 68 shows whether Discover, Offer, Request and ACK messages are exchanged and which server responds. Use Packet Capture in the Sophos Firewall Web Admin Console explains how to use this tool.

If a Discover reaches the firewall but no Offer follows, also check the status of dhcpd and the dhcpd.log log file. The relevant commands and log paths are covered in Check Sophos Firewall services and logs from the CLI.

If the client receives a correct IP address but can’t resolve names, first check the DNS addresses distributed through DHCP. If they are incorrect or missing, the fault remains in the DHCP configuration. If they are correct, check internal name resolution and network access to the DNS server next.

A RED interface has an additional edge case: If its interface address changes to an address outside the existing dynamic lease range, SFOS disables the associated RED DHCP server. Update Dynamic IP lease, static mappings, and DNS values to match the resulting interface subnet, or create a new server configuration. Only then bring the scope back into service and test it with a client.

Replace an existing DHCP server

During a migration, don’t simply enable the new DHCP server in addition to the old one. Active clients retain their existing leases; the new server isn’t aware of these assignments and could offer an address that is still in use.

Use the following procedure for a controlled change:

  1. Document the range, options, static mappings and active leases on the existing server.
  2. Shorten the lease time on the old server in advance and wait until active clients have renewed their leases with the shorter value.
  3. Stop the existing server and initially enable the new server with a non-overlapping transitional range.
  4. Renew the leases on several different clients and check the gateway, DNS and connectivity.
  5. After the old leases have expired, enable the final range and restore the normal lease time.

Conflict detection is useful during a migration, but it isn’t a substitute for this planning. The feature checks an address before assigning it, but doesn’t maintain a shared lease database with the old server.

For rollback, keep a complete record of the previous configuration. If the new scope distributes incorrect values, disable or remove only that new server configuration and bring the previous server back in a controlled manner. System services > Services > DHCP server > Stop, by contrast, stops the global DHCP service and therefore every local scope; use it only when that full impact is intended. Renew the leases on several test clients afterwards.

Special values such as PXE boot servers, VoIP controllers or vendor options must be compared separately before the change. They aren’t automatically included in the normal distribution of the address, gateway and DNS settings.

Change global DHCP settings only when required

In SFOS 23, Network > DHCP > Advanced server settings contains these two UI fields:

  • Allow only one lease per client limits each client to a single DHCP lease. When enabled, each client receives only one leased IP address.
  • Negative acknowledgement enables DHCPNAK replies when a client requests an address outside the configured server subnet or an address that is already assigned. Conflict detection, by contrast, is the separate check of an address before assignment.

Record the previous value before a UI change. Afterwards, renew a client lease, check IPv4 lease and, if needed, a UDP 67/68 packet capture. For rollback, restore exactly the recorded value. Continue to follow the CLI guidance below on global impact, client identity and NAK risks.

Two additional Device Console switches apply to the DHCP service as a whole. Read their states first:

system dhcp one-lease-per-client show
system dhcp send-dhcp-nak show

one-lease-per-client is disabled by default. The current help does not explain how the feature identifies a client in every edge case. Enabling it is global, so initially limit only the test to a controlled client; then check the lease table, lease renewal, and devices with multiple interfaces or changing MAC addresses.

send-dhcp-nak is enabled by default. A DHCPNAK rejects an address the server does not accept and sends the client back into DHCP negotiation. Turning it off can prolong an invalid client state and is not a general fix for failed leases.

Change the switches with:

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

The square brackets are placeholders; run only the required value. After a change, check the value again with show, renew a lease, inspect IPv4 lease, and capture UDP 67/68 if needed. For confirmed defaults, roll back with system dhcp one-lease-per-client disable or system dhcp send-dhcp-nak enable. If the initial state was customized, restore exactly the values captured with show before the change and verify both switches again.