Skip to content
Avanet

Configure DHCP Relay and DHCP Snooping on Sophos Switch

DHCP Relay and DHCP Snooping solve different problems. A relay forwards DHCP packets between clients and DHCP servers in different subnets, either directly to the server or, by design, through another relay. DHCP Snooping is a Layer 2 security feature: the switch accepts server replies only on deliberately trusted ports and can inspect DHCP packets on untrusted ports.

⚠️ Important: Incorrect trust-port settings can interrupt address assignment for an entire VLAN. Document the real DHCP path first, then enable and test Relay and Snooping separately with a test client. DHCP Snooping is unrelated to IGMP or MLD Snooping; multicast snooping is not part of this procedure.

Quick procedure:

  1. Decide whether DHCP Relay, DHCP Snooping, or both are required.
  2. Record VLANs, active Layer 3 VLAN interfaces, gateway/relay, DHCP servers, uplinks, and local overrides.
  3. If required, set Status and up to five Server IP addresses under L3 protocols > DHCP relay.
  4. Under L3 protocols > DHCP snooping, identify the actual ingress paths for legitimate server replies as Trusted and client ports as Untrusted.
  5. Enable Snooping globally or per VLAN; test MAC address verification separately.
  6. Validate lease acquisition, blocking of unauthorized replies, Configuration source, and Binding list.
  7. If service fails, revert the most recent change instead of trusting ports indiscriminately.

Relay or Snooping: choose the correct function

RequirementFunctionEffect
Clients and DHCP server are in different subnetsDHCP relayForwards DHCP packets to configured DHCP servers or downstream relay targets.
An unauthorized DHCP server must not serve client portsDHCP snoopingTrusts only the actual ingress paths for legitimate server replies and inspects DHCP traffic on untrusted ports.
A central server serves several VLANs and access ports need protectionBothRelay crosses the subnet boundary; Snooping protects Layer 2 access. Configure and test them separately.
Server and clients share one broadcast domain and only address assignment is neededNormally no relayAn unnecessary second relay creates an ambiguous or duplicate path. Snooping may still be useful.

Snooping replaces neither routing nor a DHCP server. Relay does not protect an access port from a rogue DHCP server. A Binding list entry is an observation, not authorization for a server port.

Prerequisites and change plan

Record the managed switch or site and working management access; every client VLAN, VLAN ID, network, and gateway/relay; and, for each relayed VLAN, an active Layer 3 VLAN interface assigned to that VLAN with an address in the client network. The switch must receive client broadcasts on that interface and associate them with the correct network.

Also record the DHCP-server or next-relay-hop addresses (at most five Server IP addresses), the complete Layer 2 path including uplinks, LAGs, and switch-to-switch links, a test port/client per VLAN, a maintenance window, and an independent management path if administrator devices use DHCP. Save the initial Status, MAC address verification, VLAN status, and trust status of every affected port.

For Relay, verify the VLAN interface is active, correctly addressed and assigned. Interface/VLAN setup belongs to the separate Layer 3/VLAN procedure. Verify routed forward and return paths between the interface and server or downstream relay, including the complete relay chain. Rules and ACLs must allow DHCP. Record existing relays on firewalls, routers, or switches so each client segment has one intentional forwarding path.

Compact topology example

Client VLAN 20 uses 192.0.2.0/24. Ports 1–20 on an access switch are Untrusted. Port 24 is Trusted on that switch only because legitimate server-side replies enter through that uplink. The relay switch has Layer 3 VLAN interface 192.0.2.1/24 and forwards to server 198.51.100.10 in 198.51.100.0/24. Routing, rules, and ACLs must permit both directions.

Trust does not transfer to equally numbered ports or other switches. On every snooping switch, trust the actual ingress port for legitimate replies; client-facing ports remain Untrusted. If Relay and Snooping run on the same switch, do not trust a port merely because it is called “uplink.”

In Sophos Fusion (formerly Sophos Central), open My Products > Switches > Switches, select the switch or site, and open L3 protocols. A site configuration can affect several switches; verify the selected object before Save.

Understand Not set

For Relay, Snooping, VLANs, MAC verification, and trust ports, Not set does not necessarily mean off: it uses the locally configured value. Configuration source shows the effective source for VLAN and trust-port settings. For a defined Central state, explicitly select Enabled, Disabled, Trusted, or Untrusted, then verify synchronization.

Configure DHCP Relay

Open L3 protocols > DHCP relay.

Exact fields

  • Status
    • Not set: Use the relay status configured locally on the switch.
    • Enabled: Enable DHCP Relay.
    • Disabled: Disable DHCP Relay.
  • Server IP addresses: Up to five DHCP-server or downstream-relay addresses to which the switch forwards packets according to the design.

Procedure

  1. Set Status to Enabled.
  2. Enter the first target in Server IP addresses and press Enter; only then is it added.
  3. Add further targets the same way, to a maximum of five.
  4. Choose whether to synchronize immediately, then select Save.
  5. Wait for the intended switch to receive the configuration and perform a controlled lease renewal in the first test VLAN.
  6. Test other VLANs one by one. Multiple targets must be designed for the relevant scopes and forwarding path.

To remove a target, select its delete icon under Server IP addresses, choose the synchronization option, and select Save.

Plan DHCP Snooping as Layer 2 protection

The trust boundary is the critical decision:

  • Trusted: Only the interface on which legitimate server-side DHCP messages enter this snooping switch: a direct server port or topology-confirmed uplink/LAG.
  • Untrusted: Normal client and other edge ports; devices there must not act as DHCP servers.

Do not trust every infrastructure port. Trust an interface only when legitimate Offer and ACK packets enter there. Direction toward a relay is insufficient: a relay on the same switch may have no physical ingress port. Derive ingress separately on every switch.

Safe rollout: Set trust ports first, then enable Snooping either globally or for selected VLANs. Sophos documents these as alternatives but gives no precedence rule when both are set. Do not combine them without model- and firmware-specific testing. Start with one VLAN. With Snooping disabled, all ports are treated as trusted and no protection is active.

Configure DHCP Snooping

Open L3 protocols > DHCP snooping. The view contains Settings, VLAN settings, Trust port settings, and Binding list.

1. Set global Settings

  • Status: Not set uses the local status; Enabled enables Snooping; Disabled disables it.
  • MAC address verification: Not set uses the local setting; Enabled checks on Untrusted ports whether the packet source MAC matches the endpoint hardware address; Disabled turns the check off.

For switch-wide protection set Status: Enabled. For selected VLANs, do not also enable global status; continue with step 2, after ensuring Not set is not inheriting a locally enabled global status. Do not infer precedence between activation levels.

Enable MAC address verification in the same change only if the normal path is known and can be tested immediately. Otherwise stabilize Snooping with it Disabled, then enable it in a separate change. Choose synchronization and Save after each selection.

2. Alternatively, set VLAN settings

In VLAN settings, select Enabled, Disabled, or Not set (local VLAN value) for each VLAN. Synchronize, select Save, and verify Configuration source. Enable only VLANs whose server ingress and trust ports are verified. Positive and negative tests determine the actual scope.

3. Set Trust port settings

Classify every affected port: Trusted for the specific ingress port/LAG carrying legitimate replies; Untrusted for client/edge ports; Not set to use local trust state. Synchronize, select Save, and verify Configuration source for critical ports. Match port labels to the cabling plan; “uplink” alone is not proof.

4. Enable MAC address verification in a controlled change

After the baseline test, set MAC address verification: Enabled, synchronize, save, and repeat a full Discover, Offer, Request, ACK exchange or lease renewal.

If a legitimate client fails, do not trust more ports. Determine whether the source MAC of the packet arriving on the Untrusted port differs from the endpoint address in the packet. Adapters, VMs, DHCP proxies, or intermediaries can alter the visible packet. Only after evidence, set verification back to Disabled or correct the intermediary design.

Read and use the Binding list

The Binding list shows learned MAC address, IP address, VLAN, and connected port. After renewal, verify the expected client, correct scope, VLAN ID, and physical access port. Reload after client changes or renewal; an old entry is not current evidence.

  • No binding: The complete exchange was not observed or followed another path.
  • Wrong VLAN: Check port assignment and tagging.
  • Wrong port: Check patching, uplinks, and downstream switches.
  • Unexpected IP: Identify the replying server and scope.

The list is display-only in this interface; there is no step here to create a static binding manually.

Validation after the change

Positive test with the authorized DHCP server

  1. Connect a test client to the intended Untrusted access port and renew its lease.
  2. Verify address, gateway, and options from the expected scope.
  3. Compare MAC, IP, VLAN, and port in Binding list.
  4. For Relay, use logs or a capture to prove the request reaches the configured target; for a downstream relay, prove arrival at the actual server. Success requires the end client to receive the expected lease.
  5. Repeat after enabling MAC address verification.

Negative test against an unauthorized DHCP server

Only in an isolated lab or maintenance window, attach a controlled rogue server to an Untrusted port. Prove by capture or server log that it sends Offer/ACK, and prove by client-side capture that those exact packets do not arrive; alternatively record an appropriate drop counter or Snooping event. A client merely choosing another offer is not proof. Then complete a lease through the authorized server. Never run this test in production where clients could receive a wrong lease.

Configuration check

Confirm Relay Status, all Server IP addresses, and that Enter committed each target; prove request arrival and a successful end-client lease. Confirm the chosen global or VLAN Snooping scope and MAC address verification, only actual server ingress ports Trusted, clients Untrusted, expected Configuration source, completed synchronization, and plausible behavior and bindings after reboot/resynchronization.

Typical symptoms and causes

Client gets no address after Snooping is enabled

Verify the actual Offer/ACK ingress is Trusted on every switch; check the selected global/VLAN status and Configuration source; remember Not set may inherit an unexpected value. Restore the documented prior MAC address verification value and compare packet and endpoint MACs. Check whether a binding is learned.

DHCP Relay provides no lease

Possible causes are Not set/Disabled or unsynchronized status; a target not committed with Enter; wrong target or the five-address limit; an inactive, wrongly addressed, or wrongly assigned Layer 3 VLAN interface; missing forward/return routing or blocking ACL/rule; incomplete downstream-relay chain; a second relay path; or a returning reply entering Snooping on a port that is not Trusted. Never trust it solely because it is labeled “relay” or “uplink.”

Unauthorized DHCP server still works

Snooping may not be effectively Enabled at the chosen scope; Not set may inherit disabled; the rogue server may be on a mistakenly Trusted port; the test may use another VLAN/path; or Snooping may be off, which treats all ports as trusted.

Central shows the desired value but behavior differs

Check synchronization, target object, and Configuration source for VLAN and port. Delayed synchronization, the wrong site object, or a local value behind Not set can explain the difference. Document Central, local source, and effective state instead of repeatedly saving.

Binding is absent or unexpected

Force a full renewal and reload. If absent, trace DHCP packet by packet. Correct tagging/cabling for wrong VLAN/port; identify the responding server and scope for wrong IP. Do not invent a manual binding.

Rollback

Rollback only the function that caused the fault, using documented initial values and Configuration source.

Revert MAC verification

Under DHCP snooping > Settings, restore MAC address verification to Disabled or intentional Not set, synchronize, Save, and renew the legitimate client lease.

Revert Snooping in the selected scope

For VLAN activation, restore only the affected VLAN in VLAN settings to Disabled or Not set. For global activation, restore global Status. Synchronize, save, and retest; do not change an unused activation level.

Setting every port to Trusted is not rollback: it removes the boundary and hides the design error. Disabling Snooping already treats all ports as trusted; document this temporary loss of protection.

Restore a trust port

In Trust port settings, restore only the changed port to documented Trusted, Untrusted, or Not set; synchronize, save, verify Configuration source, and perform a positive lease test. For a controlled rogue-server test, again prove by capture, counter, or event that Offer/ACK does not reach the client.

Revert Relay

  1. Under DHCP relay, restore Status to documented Disabled or Not set.
  2. Delete newly added targets from Server IP addresses.
  3. Choose synchronization and Save.
  4. Confirm the previous DHCP path resumes and no second relay path remains.

After every rollback, record the reason, VLANs/ports, effective configuration source, and new lease result. The change is complete only after authorized address assignment and the intended protection are both demonstrated.