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. Enable Relay through IPsec only for policy-based IPsec, not for route-based VPN. For route-based VPN, first clarify the conflicting sources described below and support for the exact build with Sophos Support; this quick flow does not establish that this setup is supported.

The example uses the client network 10.20.0.0/24, relay interface 10.20.0.1, and DHCP server 172.16.16.17. This is an IPv4 example: adapt all addresses, the client interface, and the name to your own network. The scope is the address range and network parameters from which the server assigns leases. The gateway must be in the client network and reachable; a DNS server must be reachable from the client. Before making changes, back up existing scopes, relay agents, and routes, and use a test client that obtains addresses automatically through DHCP.

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 DHCPv4 server and relay can also run on the same Sophos Firewall:

• The server listens on a different interface.
• Accept client request via relay is enabled.
• Each client subnet has its own server scope with a matching lease range, subnet mask, gateway, and DNS.

The relay agent uses the respective client interface and targets the server interface address. Clients in the server subnet continue to receive addresses directly without a relay.

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 consistent client network parameters and options, but use coordinated address allocation through server failover according to the server documentation or non-overlapping dynamic allocation ranges. 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. For this example, select IPv4 under IP version. For IPv6, don’t reuse the IPv4 addresses or UDP ports from this guide.
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 check that it appears there.
7. Leave Relay through IPsec disabled and save.

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.

XML API: Identity and IPv6 validation boundary

For automation, the same configuration belongs to the DHCPRelay object: Name identifies the relay agent, Interface the client interface, IPFamily the deliberately selected family IPv4 or IPv6, and DHCPServerIP the server list. The Add/Edit documentation for SFOS 22 and 23 marks these four fields as required; the documented default for IPFamily is IPv4. DHCPServerIP is described as an ARRAY with IPADDRESS and IPADDRESS6: multiple values are allowed, duplicates are ignored, and LINKLOCAL is excluded. Multiple relay targets therefore remain possible; the single placeholder field in the example establishes neither the list serialization format nor an IPv6 encoding. Deliberately retain the state of Relay through IPsec appropriate to the VPN variant explained below; don’t infer it from an API example.

The parameter table also specifies a maximum of 15 characters for DHCPServerIP. This limit is not generally consistent with the IPv6 address representation allowed by IPADDRESS6: the documentation is inconsistent here and does not establish how the validator in the exact build handles IPv6. This implies neither that DHCPv6 Relay is unsupported in the product nor an alternative encoding or permission to shorten addresses.

For IPv6, use the manual configuration in WebAdmin first. Before automating IPv6, clarify the schema, address validation, and server list format for the exact SFOS version and build with Sophos Support. A saved GUI configuration or a successful client lease does not confirm a valid IPv6 XML request. The client and packet-flow checks, along with rollback based on the recorded prior state, remain required as described below; do not reuse this example’s IPv4 addresses or UDP ports for IPv6.

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 and SFOS-23 help documents DHCP Relay over XFRM to an external DHCP server behind the central firewall. The described setup uses a route-based Any-to-Any tunnel. Route-based Traffic Selectors are not confirmed for this procedure.

⚠️ The official help is contradictory in SFOS 22 and SFOS 23: both the DHCP overview and Routing and NAT for IPsec tunnels state that DHCP Relay over route-based VPN is not supported. However, Add a DHCP relay and the separate route-based guide describe the following Any-to-Any setup. This does not establish confirmed product support. If the fields differ, don’t switch to policy-based options; instead, clarify the topology and exact build with Sophos Support.

⚠️ Resolve the source conflict for the exact SFOS build and topology before configuration. 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 documented setup has the following prerequisites. Until these have been clarified with Sophos Support, the details are for planning only; make configuration changes only after confirmation:

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 site, configure the client interface as the relay agent; leave Relay through IPsec disabled. The relay request is system-generated traffic there and does not need a dedicated DHCP firewall rule.

An SD-WAN route uses:

• Source: Any
• Destination: host 172.16.16.17
• Service: DHCP
• Gateway: the remote XFRM gateway

At the central site, the return route from the DHCP server to relay IP 10.20.0.1 goes through the XFRM gateway.

To prevent this traffic from falling back to another gateway if the tunnel goes down, enable Route only through specified gateways in both dedicated SD-WAN routes.

After confirmation, configure the dedicated SD-WAN routes:

1. Go to Routing > SD-WAN routes.
2. Select IPv4 > Add, and enter a clear name.
3. Under Link selection settings, select Primary and backup gateways.
4. Under Primary gateway, enter the appropriate XFRM gateway for the respective firewall; then save.

Create the firewall rule at the central site under Rules and policies > Firewall rules > Add firewall rule > New firewall rule using the hosts and service listed above.

The Destination zone must match the actual server network, such as DMZ, and is not automatically LAN.

The fail-closed option prevents fallback routing, but it also means that no new leases can be obtained through this path if the tunnel goes down.

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, enable Relay through IPsec at the branch site. 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 central firewall, two rules are required there. An existing, working tunnel is a prerequisite.

If the tunnel still needs to be created:

1. Go to Site-to-site VPN > IPsec > IPsec connections > Add and use Connection type: Policy-based.
2. Select Gateway type: Initiate the connection at the branch site and Respond only at the central site.
3. Set Listening interface to each firewall’s own WAN interface, and Gateway address to the peer’s WAN address.
4. Ensure Authentication and Preshared key match; local and remote networks are mirrored on the peer. For the external server example, these are 10.20.0.0/24 and the actual server network in use.
5. Allow IPsec access from WAN under Administration > Device access.

At the branch site, system-generated relay traffic does not need an automatically created firewall rule.

At the central site, the automatically created rules can be restricted to the DHCP hosts, zones, and services listed below. Don’t remove existing rules for other VPN traffic.

• 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, the source address of system-generated relay traffic must be set to the relay IP using sys-traffic-nat.

Run the following commands in the Device Console after logging in through SSH.

The dedicated Routing/NAT help for SFOS 22 and 23 distinguishes forwarded traffic from system-generated traffic: the latter does not require an additional system ipsec_route. However, the general DHCP overview still lists an IPsec route step.

This difference is not a reason to routinely add another route: first check the existing route and packet flow, and contact Sophos Support if the build behaves differently.

• NAT does not replace a route.
• destination remains the server address.
• snatip is the relay source address, not the server address.
• A standard WAN-MASQ rule is not a substitute for sys-traffic-nat.

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 central Sophos Firewall itself acts as the DHCP server with policy-based IPsec:

1. Create or edit a server scope under Network > DHCP > Server.
2. Enable Accept client request via relay, enter a lease range from 10.20.0.0/24, and set 10.20.0.1 as the gateway.
3. On the relay agent, enter the central firewall’s server interface as DHCP server IP; replace 172.16.16.17 in the preceding NAT example with that interface’s address.

An example for Dynamic IP lease that you can adapt is 10.20.0.10 to 10.20.0.30 with subnet mask 255.255.255.0. Gateway 10.20.0.1 and fixed infrastructure addresses remain outside the pool.

Choose the pool based on the number of clients and addresses already reserved. Use Use device’s DNS settings only if the DNS servers configured there are reachable from the branch.

For this firewall-hosted server, the policy-based selectors at the central site use the server interface address and client network; the assignment is reversed at the branch.

⚠️ 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 following in sequence:

1. Client request
2. Forwarded request
3. Server offer
4. Return path

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.

An offer alone is not enough: the client must request the address and receive an ACK. Then:

1. Check the client’s IP address from the intended pool, subnet mask, gateway, and DNS.
2. Verify the lease entry on the issuing server.

A ping response from the server proves neither UDP reachability nor a successful DHCP exchange.

These checks must be performed by the admin.

Use the following checks to narrow down common errors:

• No client request visible: Check the VLAN, switch port, client interface, or local DHCP client.
• Request reaches the firewall but is not forwarded: Check the relay interface, server IP, route, and, for policy-based IPsec, Relay through IPsec.
• Server receives the request but does not respond: Check the scope for the relay subnet, server authorization, and local server firewall.
• Offer reaches the central site but not the client: Check the return route, central firewall rules, IPsec subnets, and NAT entry.
• Client receives the wrong configuration: Identify which server responds first, and compare scopes and DHCP options on all relay targets.
• Policy rule denied with Source 0.0.0.0: A client without an address starts with this source address. Check whether a DHCP server or relay is responsible on the correct client interface; don’t create a blanket allow rule for 0.0.0.0 or Any to hide the symptom. The overview describes the drop when no server is present; in the relay scenario, check the actual packet path rather than inferring a general block on relay traffic.

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