How to set up Sophos Firewall as a DHCP server

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

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

Open Network > DHCP.
Under Server, click Add.
Enter a unique name such as dhcp-vlan20-clients.
Under Interface, select the client interface VLAN20 - 10.20.0.1.
Under Dynamic IP lease, add the range 10.20.0.100 to 10.20.0.199.
Enter 255.255.255.0 as the Subnet mask for the example /24 network.
Select Use interface IP as gateway. Clients then receive 10.20.0.1 as their Gateway.
Set the DNS servers, Domain name, and lease times to suit the network.
Add static MAC-to-IP mappings if required.
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 check the local, command-specific help for conf-generation-method and static-entry-scope in the Device Console on the installed SFOS version. Establish and record the current method and scope using a read-only query supported there or an available UI display; also verify the corresponding rollback syntax in advance. No single show form is confirmed here for every version. If the initial state or rollback procedure cannot be reliably established, do not make any changes and clarify the state with support first.

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.

When MAC addresses have multiple bindings, the target state shown above is important to ensure that clients receive the correct DHCP settings, such as DNS servers and the gateway. Do not overwrite a state that already matches the requirements, and do not assume defaults as the initial state. For rollback, restore exactly the values recorded beforehand using syntax confirmed for the installed version. If the initial values were actually network and old, system dhcp static-entry-scope network and system dhcp conf-generation-method old are possible rollback commands, provided the local help confirms these forms. 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.

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

⚠️ 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.

ipconfig /release
ipconfig /renew
ipconfig /all

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:

The client receives an address from the correct range.
The gateway and DNS servers match the plan.
The gateway is reachable.
Internal and external names are resolved.
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:

Document the range, options, static mappings and active leases on the existing server.
Shorten the lease time on the old server in advance and wait until active clients have renewed their leases with the shorter value.
Stop the existing server and initially enable the new server with a non-overlapping transitional range.
Renew the leases on several different clients and check the gateway, DNS and connectivity.
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.

Automation: status of a named DHCP configuration

The XML API documentation for SFOS 22 and 23 describes DHCPServerStatus with the required fields DHCPServerNamedhcpname and Status. DHCPServerNamedhcpname is the literal documented spelling, not a field name corrected here. The name identifies the selected DHCP server configuration, such as dhcp-vlan20-clients, not the global DHCP service. A status change for this named scope must not be confused with the global Stop described above.

For Status, the example shows ON/OFF, whereas the parameter table specifies INTEGER. No numeric mapping or default is given; both fields are required. This establishes neither a safe encoding nor behaviour when fields are omitted. Do not automate an XML status change from this example. Until the field schema and status encoding are clarified for the installed version, continue using the existing GUI procedure under Network > DHCP for the selected server configuration; control the global service separately under System services > Services.

Before a change, record the target scope’s name, interface, address range and previous status. Afterwards, check that exact configuration and that other scopes remain unchanged, and perform the lease, gateway, DNS and connectivity checks described above with controlled clients. When disabling the scope, verify that it no longer issues new leases; a client lease that still exists does not prove this. The documented API results 200 (Operation Successful) and 500 (Operation Fail) are not functional checks; HTTP 200 alone also confirms neither the correct target nor the client state. For rollback, restore exactly the recorded state and repeat the client checks.

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. Before making a change, check the local, command-specific help for one-lease-per-client and send-dhcp-nak on the installed version. Record the current state of both switches using a read-only query supported there or an available UI display, and confirm the change and rollback syntax. Neither a specific show form nor a default is assumed here for every version. If the initial state or rollback procedure cannot be reliably established, do not make any changes and involve support first.

one-lease-per-client limits lease assignment per client when enabled. How the installed version identifies the client in edge cases must be established locally. Enabling it applies to all DHCP server configurations on this firewall; therefore, initially restrict only the test to a controlled client, then check the lease table, lease renewal, and devices with multiple interfaces or changing MAC addresses.

Enabling send-dhcp-nak allows DHCPNAK replies. A DHCPNAK rejects an address the server does not accept and forces the client back into DHCP negotiation. Turning it off can prolong invalid client states and is not a general fix for failed leases.

Change the switches as follows only if the local help confirms this syntax for the installed version and the initial state and rollback procedure have been recorded:

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 the change, check the value again using the same supported read-only query or UI display, renew a lease, inspect IPv4 lease, and perform a packet capture on UDP 67/68 if needed. For rollback, restore exactly the values recorded before the change using the syntax confirmed in advance, and check both switches again. system dhcp one-lease-per-client disable and system dhcp send-dhcp-nak enable are appropriate rollback values only if the first switch was previously disabled or the second was previously enabled, respectively, and the local help confirms this syntax.