Sophos Firewall DHCP Options (SFOS)

DHCP options are required on the Sophos Firewall when clients need more than just an IP address, gateway, and DNS at startup. Typical cases include PXE, WDS, thin clients, VoIP phones, or older RED environments where a specific option code and data type must match exactly.

Current Sophos Firewall versions support DHCP options directly in WebAdmin. Therefore, SSH or CLI configuration is no longer necessary for most environments. However, CLI examples remain important because older runbooks, special cases, and troubleshooting often still use this syntax.

What DHCP Options Are

DHCP not only distributes an IP address. Along with the lease, the DHCP server can pass additional information to the client. This is exactly what DHCP options are for. Typical examples include DNS servers, gateways, TFTP servers, boot file names, vendor-specific parameters, or values for thin clients and phones.

On the Sophos Firewall, DHCP options always belong to the DHCP server or the scope that issues the lease. This is important: if a client receives its address from another DHCP server, the option must be configured there. If the Sophos Firewall only acts as a DHCP relay, it forwards DHCP requests but is not the place where the option for this scope is maintained.

For IPv6, DHCP is not always treated the same as for IPv4. When a provider delegates an IPv6 prefix, router advertisement, DHCPv6 parameters, and firewall rules belong together. The process is described in Configure IPv6 Prefix Delegation on Sophos Firewall.

In practice, you should clarify three things before configuration:

• Which DHCP server actually distributes the lease?
• In which scope or on which interface is the client located?
• What option codes, data types, and values does the target system’s manufacturer require?

Prerequisites

• Sophos Firewall with enabled DHCPv4 server
• Access to Network > DHCP
• A DHCP scope on the appropriate interface
• The required DHCP option codes and values from the manufacturer or target system
• For CLI fallbacks: allowed SSH access to the Sophos Firewall

Before making changes, you should briefly check the affected scope. DHCP options only work reliably if they are set on the correct DHCP server, in the correct network, and with the correct data type.

• DHCP Server: The Sophos Firewall must issue the lease itself. With DHCP relay, the options usually belong on the central DHCP server.
• Scope and Interface: A client in the wrong VLAN or on another interface will not see the option, even if it is correctly stored.
• Option Code and Data Type: Many errors occur because a client expects string, ipaddress, array-of, or a vendor value differently from what was entered.
• Test Client: A known device in the affected network makes it visible whether the option really arrives in the DHCP offer or ACK.
• Change Window: PXE, phones, and thin clients can be affected immediately when the lease changes. Changes should therefore be tested in a controlled way.

If the option is relevant for productive devices, it should be clear in advance how to remove it or reset it to the old value. This is especially true for boot options, provisioning servers, and manufacturer-specific vendor options.

1. Create or Check DHCP Server

To distribute DHCP options, you first need a DHCPv4 server on the Sophos Firewall. This is created or edited in WebAdmin under Network > DHCP.

The most important points are:

• The DHCP server is assigned to an interface.
• The scope matches the network where the clients are located.
• DNS server, gateway, and lease time are set correctly.
• The DHCP name contains no unnecessary spaces or special characters.
• PXE, VoIP, thin client, or RED special cases are documented in advance.

The DHCP name is particularly relevant for CLI commands. If the name contains spaces or special characters, later commands and runbooks become unnecessarily error-prone. Understandable names like DHCP_Server_Avanet_LAN, Home_Scope, or DHCP_VoIP are easier in practice.

2. Configure DHCP Options in WebAdmin

Once the DHCPv4 server is created, the options can be added directly in the same dialog.

1. Open Network > DHCP.
2. Edit the existing DHCPv4 server or create a new server.
3. Switch to the DHCP options section.
4. Add option.
5. Enter Option, Code, Type, and Value.
6. Save changes.
7. Check with a test client whether the option is really adopted.

The fields mean:

• Option: Name of the option. For predefined options, you can select them; for custom options, use a meaningful name.
• Code: Numeric DHCP option code, for example 66, 67, 161, or a manufacturer-specific value.
• Type: Data type of the value, for example ipaddress, string, boolean, one-byte, two-byte, four-byte, or array-of.
• Value: The specific value the client should receive, such as an IP address, a hostname, a path, or a port.

The correct values are usually provided by the manufacturer of the target system. Especially for string values, path specifications, or vendor-specific options, it is worth checking against the manufacturer’s documentation. A formally stored value does not automatically mean that the client interprets it as expected.

3. Typical Use Cases

DHCP options are usually needed when a client requires additional information at startup. Common cases include PXE, WDS, thin clients, VoIP phones, access points, or individual legacy scenarios.

PXE and WDS

For PXE or WDS environments, options 66 and 67 are often used:

• 66 refers to the TFTP or deployment server.
• 67 contains the boot file name.

If the client reaches the server but does not boot, the problem often lies not with the firewall but with an incorrect file path, an unsuitable data type, or an inappropriate architecture file. Different boot files are often required for UEFI and BIOS clients.

Thin Clients

Thin clients require options for management servers, image servers, or connection parameters depending on the manufacturer. In old runbooks, you might find, for example:

• 161 for the server
• 192 for a port or additional parameters

Whether these codes are correct depends on the manufacturer and the thin client model used. Therefore, you should not blindly adopt the codes but always check against the manufacturer’s documentation.

Older RED Special Cases

In older environments, there were cases where a Sophos RED 15w’s integrated access point was not correctly recognized. A manufacturer-specific DHCP option was sometimes used for this, for example, with option code 234 and a value like 10.10.10.12.

This is not a general standard for modern SD-RED installations. However, as a legacy example, it remains useful because it shows how to define custom option codes and bind them to a DHCP server.

For current RED designs, the article Set up and troubleshoot Sophos SD-RED is more helpful. For interface, VLAN, bridge, or RED designs, Plan and configure Sophos Firewall zones and interfaces is also helpful.

4. When DHCP Relay is Relevant Instead of DHCP Server

Sophos Firewall can not only be a DHCP server itself but also use DHCP relay. In this case, DHCP requests from clients are forwarded to a DHCP server in another network.

This is especially relevant when IP addresses are centrally assigned by a Windows DHCP server or another dedicated DHCP system. In such designs, DHCP options are usually maintained on this central DHCP server, not on the Sophos Firewall.

For VPN, XFRM, RED, or branch office designs, you should first check:

• Should the Sophos Firewall distribute leases itself?
• Should it only forward DHCP requests?
• Is the client in a directly connected network?
• Are there multiple DHCP servers that could accidentally respond to the same client?

If the wrong DHCP server responds, even the most correct DHCP option on the Sophos Firewall will not help.

5. When the CLI is Still Useful

For current standard configurations, WebAdmin is usually sufficient. The CLI is still useful if:

• an old article or older runbook is already based on CLI commands
• unusual vendor options need to be tested
• you want to see exactly which bindings are stored internally in a support case
• an environment has been taken over from a very old SFOS version
• a command needs to be replicated or checked in documentation

If you need to go this route, you should first check the guide Connect to Sophos Firewall via SSH. After logging in, the 4. Device Console is used for the following commands.

CLI Basic Principle: Define and Bind Option

In CLI configuration, there are two steps:

1. The DHCP option is defined.
2. The option is bound to a DHCP server and given a value there.

First, the option is defined:

system dhcp dhcp-options add optioncode optionname optiontype

The placeholders mean:

• optioncode: numeric DHCP option code
• optionname: freely chosen name of the option
• optiontype: data type, for example, ipaddress or string

Example for an IP address as a DHCP option:

system dhcp dhcp-options add optioncode 234 optionname dhcp_magic_ip optiontype ipaddress

Then the option is bound to a DHCP server:

system dhcp dhcp-options binding add dhcpname optionname(234) value

The placeholders mean:

• dhcpname: name of the DHCP server from the Sophos Firewall configuration
• optionname(234): name of the previously defined option including option code in parentheses
• value: value to be distributed to clients

Example:

system dhcp dhcp-options binding add dhcpname dhcp_red_avanet optionname dhcp_magic_ip(234) value 10.10.10.12

6. CLI Examples

The following examples are still useful templates if an option needs to be set via the Device Console or an old runbook needs to be followed. These commands are not incorrect; they are just not the first choice in current standard environments.

Thin Client Server

This option informs a thin client on which server the image or management component is located:

system dhcp dhcp-options add optioncode 161 optionname ThinClientServer optiontype ipaddress
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServer(161) value '10.10.10.12'

If a port is also needed, it can be set as a string:

system dhcp dhcp-options add optioncode 192 optionname ThinClientServerPort optiontype string
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServerPort(192) value '443'

WDS and PXE

A DHCP option value for the WDS or TFTP server can be set as follows:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname TFTP_Server_Name(66) value 172.16.16.11

The boot file name for the pre-environment is provided as option 67:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname Bootfile_Name(67) value \boot\x64\wdsnbp.com

The pre-environment refers to the boot environment with which a client starts during installation or recovery. Depending on the environment, the required path may vary, especially for UEFI, BIOS, 32-bit, and 64-bit clients.

Display Existing Options

Before making changes, you should display existing options:

system dhcp dhcp-options list

Display bindings of a DHCP server:

system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN

An option can be deleted if necessary:

system dhcp dhcp-options delete optionname dhcp_magic_ip(234)

7. Common Sources of Error

If a DHCP option is stored but does not work as expected on the client, it is often due to one of these points:

• The wrong DHCP server responds to the request.
• The wrong scope or interface was edited.
• The data type does not match the expected value.
• IP address, FQDN, port, or path is mistyped.
• Boot file path does not match the client architecture.
• Client expects a string, but the option was created as an IP address.
• Manufacturer uses vendor-specific options that require additional parameters.
• Lease was not renewed after the change.
• DHCP relay is used, although the option was maintained on the Sophos Firewall.

After a change, you should renew the lease on the test client and check whether the client really receives the expected options. If the behaviour still does not fit, a packet capture is often faster than long guessing: in the DHCP packets, you can see which server responds and which options are actually delivered.

8. Test Change

After saving a DHCP option, you should not just wait until the next client eventually fetches a new lease. A controlled test with a known device in the affected network is better.

Sensible procedure:

1. Connect the test client to the correct VLAN or interface.
2. Renew the old lease or restart the client.
3. Check which DHCP address, gateway, DNS server, and additional options have arrived.
4. Test the target system, for example, PXE boot, WDS start, thin client registration, or phone provisioning.
5. Check in WebAdmin whether the lease appears in the expected DHCP scope.
6. If the result does not fit, use Packet Capture to check which DHCP server responds and which options are included in the offer or ACK.

For a narrow capture, a filter on UDP 67 and 68 between the client and DHCP server is usually sufficient. The operation of the WebAdmin tool is described in Use Sophos Firewall Packet Capture in WebAdmin.

For PXE and WDS tests, you should also document whether the test client uses BIOS or UEFI. Many boot problems do not arise from DHCP itself but from a boot file that does not match the architecture.

9. Troubleshooting by Symptoms

If DHCP options do not work, a symptom-oriented check often helps faster than recreating the same option.

• Client does not receive an IP address: DHCP server, VLAN, interface, or relay does not match. Check lease list, interface, VLAN, and DHCP Relay.
• Client receives IP but no option: Wrong scope or wrong DHCP server responds. Check Packet Capture for DHCP offer or ACK.
• PXE finds server but does not boot: Option 67, file path, or architecture does not match. Check BIOS/UEFI boot file and TFTP/WDS log.
• Thin client does not connect: Wrong option code, type, or manufacturer value. Compare manufacturer documentation and delivered value.
• Change only takes effect later: Client is using an old lease. Renew the lease, restart the client, or consider the lease time.
• CLI command does not work: DHCP name, option name, or bracket notation is wrong. Check system dhcp dhcp-options list and the binding output.

If another DHCP server responds in the capture, the network design should be clarified first. Two DHCP servers in the same broadcast domain are a classic cause of changing behaviour. For more complex VLAN, bridge, or interface questions, Plan and configure Sophos Firewall zones and interfaces is helpful.

Frequently Asked Questions