Set up and test DHCP Relay on Sophos Firewall

A DHCP relay forwards DHCP requests from a client network to a server in another network. On Sophos Firewall, go to Network > DHCP, add an agent under Relay for the client interface, and enter the DHCP server’s IP address.

Quick flow: Select the client interface, enter the DHCP server, check the matching scope and return path on the server, renew the lease, and capture the exchange with port 67 or port 68. Turn on Relay through IPsec only for policy-based IPsec, not for route-based VPN.

The example uses the client network 10.20.0.0/24, relay interface 10.20.0.1, and DHCP server 172.16.16.17.

Requirements and limitations

The DHCP server must have a scope for 10.20.0.0/24. Sophos Firewall doesn’t issue the lease itself; it uses the relay interface address so that the server selects the correct scope. The relay needs a route to the server, and the server needs a return path to 10.20.0.1. If the firewall is to issue addresses directly to clients on the connected network instead, see Configure Sophos Firewall as a DHCP server. DHCP options are configured on the server that issues the lease.

A DHCPv6 server and DHCPv6 relay can’t be active at the same time. If the firewall is to distribute IPv6 addresses itself, Set up a DHCPv6 server on Sophos Firewall explains the separate procedure with Router Advertisement, DUID and lease validation.

The following limitations apply:

• The relay interface must be in the same subnet as the clients and must not be the DHCP server’s interface.
• Relay agents can use physical and virtual interfaces such as VLAN, wireless, or bridge interfaces, but not an interface alias.
• Don’t create a relay agent in the DHCP server’s subnet.
• Create a separate relay agent for each client subnet.
• You can add up to eight DHCP servers to each relay agent. The request is sent to all of them, and the client uses the first offer.
• A DHCPv4 server and DHCPv4 relay can run on the same firewall, but not on the same interface.
• A DHCPv6 server and DHCPv6 relay can’t be active on the same firewall at the same time.
• The client and relay use UDP 67 and 68; the relay and server communicate over UDP 67. The server needs a return path to the relay IP 10.20.0.1.

Multiple relay targets should provide identical scopes and options for the same client. Different replies otherwise lead to behavior that is difficult to reproduce.

Set up DHCP Relay without a VPN

1. Go to Network > DHCP.
2. Under Relay, click Add.
3. Enter a clear name such as relay-clients-vlan20.
4. Select the IP version.
5. Under Interface, select the client interface VLAN20 - 10.20.0.1.
6. Under DHCP server IP, enter 172.16.16.17, click the plus button to add it to the list, and verify that it appears there.
7. Leave Relay through IPsec turned off and save the configuration.

Then renew a lease from a test client. Relay requests are system-generated traffic, so this procedure doesn’t need a dedicated firewall rule on the relay firewall. Devices between the relay and server must still allow UDP 67 in both directions; the client segment uses UDP 67/68. If the client doesn’t receive an address, first check that the server has a scope for 10.20.0.0/24 and knows a route to the relay interface. For VLAN issues, see Configure a VLAN interface on Sophos Firewall.

Change the Relay Refresh Interval Only Deliberately

Device Console shows the global interval for DHCP Relay refresh packets with:

system dhcp dhcp-relay-refresh-interval show

The documented default is 10 seconds. Sophos states two different upper limits on the same SFOS 22 page: The syntax shows 10000, while the option description states 1000 seconds. Do not use a value above 1000 based only on the syntax line. Confirm any exceptional requirement with Sophos Support first.

The change uses this template:

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

Replace the placeholder with a verified value. Do not change the interval as general tuning; it cannot repair a missing server scope, routing, IPsec, or firewall rules. Record the current value first, then use show, obtain a new client lease, and check the UDP 67/68 packet flow. Rollback restores the value read beforehand.

DHCP Relay over route-based IPsec

The SFOS 22 help documents DHCP Relay over XFRM to an external DHCP server behind the head office firewall. The documented design uses a route-based Any-to-Any tunnel. Route-based Traffic Selectors aren’t confirmed for this procedure.

⚠️ The official help is inconsistent here: The DHCP overview says that relay agents currently can’t be created over route-based VPNs. However, Add a DHCP relay and the dedicated route-based procedure describe the following design. Don’t generalize this support statement to other route-based designs. If the fields differ in your SFOS 22 build, don’t substitute policy-based options; confirm the build behavior with Sophos Support.

⚠️ The source conflict remains unresolved; the design is documented, not confirmed or tested as a product capability. Before implementing it, Sophos Support must clarify support for the exact SFOS build and Any-to-Any topology with an external DHCP server. That confirmation is a prerequisite, not evidence already held here. Until it is clarified, do not make route-based configuration changes using this procedure.

The following are required:

1. Any-to-Any IPsec connections on both firewalls.
2. Addressed XFRM interfaces with a gateway.
3. Static, SD-WAN, or dynamic routes on both firewalls: from the relay to the DHCP server and back to the relay IP 10.20.0.1 for the reply.
4. IPsec access allowed under Administration > Device access for the WAN interfaces involved.
5. A rule at the head office from VPN to the server zone with Source 10.20.0.1, Destination 172.16.16.17, and Service DHCP.

At the branch office, configure the client interface as the relay agent and leave Relay through IPsec turned off. The relay request is system-generated traffic and doesn’t require its own DHCP firewall rule at the branch. An SD-WAN route uses Source Any, the host 172.16.16.17 as Destination, Service DHCP, and the remote XFRM gateway. At the head office, the return route sends traffic from the DHCP server to relay IP 10.20.0.1 through the XFRM gateway. To prevent this traffic from falling back to another gateway when the tunnel is down, turn on Route only through specified gateways in both dedicated SD-WAN routes.

The general VPN rules for the Any-to-Any tunnel must also be in place. Set up Site-to-Site IPsec on Sophos Firewall explains the tunnel and XFRM route configuration in detail.

⚠️ This route-based procedure applies to an external DHCP server behind the head office firewall. A Sophos Firewall interface configured as the central DHCP server isn’t supported for this design.

DHCP Relay over policy-based IPsec

For policy-based IPsec, turn on Relay through IPsec at the branch office. The local and remote subnets of the IPsec connection must cover the relay interface and DHCP server. If an external DHCP server is behind the head office firewall, two rules are required there:

• VPN to the server zone: relay network to DHCP server, Service DHCP.
• Server zone to VPN: DHCP server to client network, Service DHCP.

For the documented policy-based procedure, sys-traffic-nat must set the source address of the system-generated relay traffic to the relay IP. Run the following commands in the Device Console after signing in through SSH. In SFOS 22.0, this system-generated traffic doesn’t require an additional system ipsec_route.

Record the current state before making the change:

show advanced-firewall

⚠️ sys-traffic-nat add changes the global NAT configuration for system-generated traffic. The destination and source address must match the IPsec tunnel and return path.

For this example, set the relay interface address as the source address toward the DHCP server:

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

Then run show advanced-firewall again and verify that this exact entry exists. The server must be able to reach 10.20.0.1 through the tunnel. If the same entry existed before this change, it isn’t part of this procedure’s rollback.

To roll back an entry added by this procedure:

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Create an IPsec route on Sophos Firewall explains additional policy-based routing scenarios and procedures for older SFOS versions.

When the head office firewall is the DHCP server

Only in this policy-based scenario, where the head office Sophos Firewall itself is the DHCP server, leave Create firewall rule cleared in the IPsec connections on both firewalls. DHCP communication with the firewall-local server is not the same as forwarding traffic to an external server; the head office forwarding rules described above belong to the external-server scenario. Keep WAN IPsec access under Administration > Device access and any rules required for other VPN user traffic.

If the head office Sophos Firewall is itself the DHCP server over policy-based IPsec, create or edit a server scope under Network > DHCP > Server. Turn on Accept client request via relay, enter a lease range from 10.20.0.0/24, and set 10.20.0.1 as the gateway. On the relay agent, enter the head office firewall’s server interface under DHCP server IP; its address then replaces 172.16.16.17 in the preceding NAT example.

⚠️ Check the version before a global change: The following enable workflow applies only to the documented SFOS 22 scenario. The available SFOS 23 help pages conflict: HO firewall as DHCP server and BO firewall as relay agent describes DHCP lease over IPsec as enabled by default with no additional configuration; the DHCP overview still instructs administrators to turn it on through the CLI. This conflict remains unresolved. It establishes neither the actual state after an upgrade nor that the command has been removed. On SFOS 23, do not routinely enable the global setting: record the exact build and current state, and first confirm whether a change is needed with Sophos Support. If the state is unclear or the status command is unavailable, stop before making a change.

Record the exact SFOS build and, before any change, display and save the current state in the Device Console on the lease-issuing head office firewall:

system dhcp lease-over-IPSec show

⚠️ The following setting applies globally to DHCP leases over IPsec. Turn it on only on the firewall that issues the leases. Record the displayed initial state so that rollback doesn’t disable a pre-existing configuration.

Only on SFOS 22, if the recorded state is disabled, turn it on and then verify it with the preceding show command. If it is already enabled, make no change:

system dhcp lease-over-IPSec enable

Only if the feature was previously disabled on the lease-issuing head office firewall and was actually enabled during the authorized procedure, roll it back with:

system dhcp lease-over-IPSec disable

If it was already enabled, leave it enabled. In either case, system dhcp lease-over-IPSec show confirms the restored state.

Test the configuration and troubleshoot errors

A saved relay agent alone doesn’t prove that the configuration works. Renew the lease from a test client, then set a narrow filter under Diagnostics > Packet capture > Configure in the Enter BPF string field:

port 67 or port 68

The packet flow should show the client request, forwarded request, server offer, and return path in sequence. The In interface, Out interface, Source IP, Destination IP, Ports [src, dst], and Status columns show where the exchange stops. Relay packets may appear as Generated or Forwarded. For Violation, Reason provides the next troubleshooting clue. Packet Capture in Sophos Firewall WebAdmin explains the controls and fields.

Use the following checks to narrow down common errors:

• No client request is visible: Check the VLAN, switch port, client interface, or local DHCP client.
• The request reaches the firewall but isn’t forwarded: Check the relay interface, server IP, route, and Relay through IPsec for policy-based IPsec.
• The server receives the request but doesn’t reply: Check the scope for the relay subnet, server authorization, and local server firewall.
• The offer reaches the head office but not the client: Check the return route, head office firewall rules, IPsec subnets, and NAT entry.
• The client receives an incorrect configuration: Identify which server replies first, then compare the scopes and DHCP options on all relay targets.

Roll back the configuration

For a planned rollback, first make sure that clients can reach another DHCP server. Then delete the relay agent under Network > DHCP > Relay. Remove dedicated routes, host objects, and rules only after Packet Capture no longer shows relay requests; keep objects shared with other VPN traffic. For policy-based IPsec, also delete only the sys-traffic-nat entry created by this procedure. Restore lease-over-IPSec only on the head office firewall that itself issues the leases, and only if its state was actually changed during the authorized procedure; restore the state recorded beforehand. This is not part of rollback for relay to an external DHCP server or an unchanged state.

Frequently asked questions