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.

SFOS 22 supports predefined and custom DHCP options directly in WebAdmin. This is the verified standard method. Older runbooks often contain more detailed Device Console syntax; below, it is deliberately identified as a migration reference, not as unverified copy-and-paste guidance for SFOS 22.

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 Sophos Firewall. The complete basic configuration, including the address range, gateway, DNS, lease time and testing, is described in Configure Sophos Firewall as a DHCP server. The server can then be edited 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

The complete SFOS 22 path for a new scope is Network > DHCP > Server > Add. For an existing scope, open its edit action there. The DHCP options section is inside that server form.

1. Open Network > DHCP and edit the correct DHCPv4 server under Server.
2. Record every existing row under DHCP options, including option, code, type, and value. This is the baseline for rollback.
3. Select a predefined option from the list or add a custom option.
4. For a custom option, complete Code, Type, and Value.
5. Select Save.
6. Renew the lease on a controlled test client and inspect the option delivered to it.

SFOS 22 distinguishes between:

• Predefined options: A list of DHCP options offered by SFOS with their default values. The official mapping includes data types such as String, IP address, Boolean, One-byte numeric value, Two-byte numeric value, Four-byte numeric value, and several array types.
• Code: The custom or vendor option number. Obtain it from the current client vendor documentation or the IANA registry.
• Type: The data type used to encode Value. Both the visible value and its encoding must match the client specification.
• Value: The value actually sent, such as an IP address, FQDN, path, or vendor-specific string.

The target system’s vendor normally provides the correct values. A value that SFOS saves without an error is not proof that the client interprets its code, type, and content as intended.

Prepare the Change and Rollback

Apply a change to one controlled scope first. Before selecting Save, record each affected option row and its old value. If the test fails, edit the same DHCPv4 server, remove only the newly added row or restore the recorded old value, and save. Renew the test client’s lease again and inspect the DHCP Offer or ACK to confirm that the baseline is being delivered.

Do not hastily delete a global option definition from the CLI: another DHCP server may still use it. Restoring the affected scope is normally sufficient for a safe rollback.

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.

Important for current SFOS versions: Next-server and Boot file are separate boot option fields in the DHCPv4 server. Since SFOS 20.0 MR1, they are no longer automatically treated only as DHCP options 66 and 67. If a device explicitly expects option 66 or 67, maintain these values deliberately under DHCP options and don’t only fill in the boot option fields.

When upgrading to SFOS 20.0 MR1 or later, existing Next-server and Boot file values are retained as boot options and also as DHCP options 66 and 67. After a migration, check whether values exist twice and whether the client evaluates the expected variant.

SFOS accepts an IP address or FQDN in Next-server, but not a URL. Boot file requires the full path including the file name. Both values must match the boot server actually in use and the client architecture.

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.

Avaya IP phones as a specific vendor example

The SFOS 22 help uses options 176 and 252 as String values for Avaya phones. Its IP addresses and port are documentation values only and must be replaced with the actual communication, TFTP and HTTP servers in the environment:

Option 176, String: MCIPADD=192.168.30.99,MCPORT=1719,TFTPSRVR=192.168.30.201
Option 252, String: ConfigHttpSrvr=192.168.30.102

After renewing the lease, inspect the DHCP Offer or ACK to confirm that the client receives these exact strings. Then use the phone and server logs to verify that the device actually uses the intended services. This example isn’t a universal Avaya configuration.

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. Put DHCP Relay in the right context

With DHCP Relay, Sophos Firewall forwards client requests to a server in another network. Therefore, DHCP options are configured on the server that issues the lease, not on the relay firewall.

Set up and test DHCP Relay on Sophos Firewall explains interface selection, multiple servers, local networks, and policy-based and route-based IPsec with example values, rules, commands, and Packet Capture.

5. Use the CLI in a Controlled Way

SFOS 22 still documents both CLI steps: define an option with system dhcp dhcp-options add, then bind it to a DHCP server with system dhcp dhcp-options binding add. The current Device Console overview only summarizes the command, while the official Avaya procedure shows the complete syntax. WebAdmin remains clearer for new standard configurations; the CLI is mainly useful for existing runbooks, support cases, and controlled migrations.

Consider the Device Console only 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 must use syntax confirmed for the installed release, first read Connect to Sophos Firewall via SSH. After login, use 4. Device Console, not Advanced Shell. Back up the current UI configuration and existing bindings before any change.

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 syntax for defining and binding options is officially documented in the current SFOS 22 Avaya procedure. The thin-client, WDS, and RED values below are environment-specific examples, however: verify each option code, data type, and value against current vendor documentation before use.

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

The official SFOS 22 procedure notes that the firewall supports option objects 1 through 255, but this CLI command only displays options 1 through 76. Appendix A, the IANA registry, and the client or vendor documentation remain authoritative for codes, types, and encoding.

Display bindings of a DHCP server:

system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN

Although the current command summary includes a delete action, global deletion isn’t a safe default rollback: you would first have to establish whether other DHCP servers use the definition. For a change to one scope, restore the recorded previous state in WebAdmin instead.

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