Plan Sophos Firewall zones and interfaces correctly
A zone groups interfaces with a similar level of trust. An interface is a physical or virtual connection, such as Port1, a VLAN, LAG, RED or XFRM interface. Each bound interface belongs to exactly one zone; physical ports can also remain unbound.
Important: A zone does not automatically allow traffic. Even between two interfaces in the LAN zone, a suitable LAN-to-LAN firewall rule is required. Access to the firewall itself, such as WebAdmin, SSH or DNS, is additionally controlled through Device Access.
Configure zones and interfaces directly
Create a zone
Go to Network > Zones > Add to create a custom zone in four steps:
- Enter a clear name, such as
Server,Management,GuestorIoT. - Select
LANorDMZas the Type. - Under Device Access, allow only the local firewall services that are actually required from this zone.
- Save the zone.

The zone should then appear under Network > Zones and be available as a Source zone or Destination zone in a firewall rule. Production traffic only uses the zone after at least one interface has been assigned to it.
Custom zones can only be created with the LAN or DMZ type. Additional WAN or VPN zones cannot be created. SFOS automatically assigns VPN interfaces to the VPN zone. The firewall supports up to 100 zones in total.
Configure a physical interface
Edit an existing port under Network > Interfaces by selecting Edit interface:
- Enter a descriptive Name, such as
Core Switch TrunkorMPLS Provider. - Select the appropriate Network zone.
- Configure IPv4 and, if required, IPv6.
- For WAN interfaces, check the gateway and, where applicable, MTU and MSS.
- Save the interface, then check the link status, gateway status and Log Viewer.

Only interfaces in the WAN zone have a gateway configuration. Internal interfaces normally use static addressing; WAN connections can use static addressing, DHCP or PPPoE.
For a specific task, use one of these focused guides:
- Set up and test a VLAN interface
- Configure a LAG interface
- Set up Sophos SD-RED
- Secure Device Access
- Set up a site-to-site IPsec VPN
Plan the zone model
Distinguish between zones, interfaces and network objects
These three elements serve different purposes:
- Zone: identifies the security area that traffic comes from or goes to.
- Interface: connects the firewall physically or virtually to a network.
- Network object: identifies the specific IP address or subnet in a rule.
A rule is only precise when both the zone and network object are correct. Source zone: LAN combined with Source networks: Any is often unnecessarily broad. Conversely, a correct network object does not help if the packet enters through a different zone than the one specified in the rule.
The default zones have fixed roles:
LANfor internal networksWANfor provider and internet connectionsDMZfor exposed or particularly isolated systemsWiFifor wireless contextsVPNfor remote access and site-to-site tunnels
Custom LAN zones are suitable for areas such as Client, Server, Management, Guest, IoT, VoIP, Backup or OT. A custom DMZ zone is appropriate for published servers, reverse proxies or other systems whose access to the internal network must be tightly restricted.
Not every VLAN needs its own zone. Multiple VLANs can share a zone when their trust level, firewall rules and Device Access settings are identical. If their permitted destinations, management access or security features differ, a separate zone is usually clearer.
Do not create custom VPN zone types for VPN users or site tunnels. Segmentation within the VPN zone is achieved with precise network objects, users and firewall rules.
Define traffic directions before creating rules
Before configuration, a short list of permitted directions is sufficient. For example:
ClienttoWAN: required web, DNS, NTP and application servicesClienttoServer: defined application ports onlyGuesttoWAN: internet access, but no access to internal networksIoTtoServer: only required destinations such as DNS, NTP or a management platformManagementto internal zones: tightly restricted and logged administrative servicesDMZtoLAN: blocked by default, with only explicitly required connections allowedVPNtoServer: approved destinations and services only
For each permitted direction, document the destination, services, NAT requirements, logging and owner. These details form the actual rules. Configure Sophos Firewall rules correctly explains their structure, order and matching behavior.
Check before making a change
Before creating or moving an interface, clarify at least the following points:
- zone and trust level of the network
- IP address, subnet and default gateway
- DHCP source and DNS servers
- required local firewall services
- firewall and NAT rules
- routing and SD-WAN
- test client, expected access and expected log entry
Production changes also require a current backup, a rollback path and a check under Object usage.
Create and validate a VLAN
Create a VLAN under Network > Interfaces > Add interface > Add VLAN. The key settings are:
- Interface: physical, RED, bridge or LAG interface on which the tagged VLAN arrives
- Network zone: security area for the VLAN
- VLAN ID: must match the switch and, where applicable, the access point
- IPv4/IPv6 configuration: usually a static gateway address for an internal VLAN

For example, a guest VLAN could use Port3, VLAN ID 20, the Guest zone and gateway address 192.168.20.1/24. On the switch, VLAN 20 must be tagged on the uplink to Port3; a client port or guest SSID then assigns endpoints to this VLAN.
The firewall can display the interface correctly even if the switch sends the VLAN on the wrong port, untagged or with a different VLAN ID. A VLAN is therefore only complete after the entire path has been tested:
- Check the VLAN ID, parent interface, zone, IP address and subnet mask on the firewall.
- Configure the uplink to the firewall as a trunk with the VLAN tagged.
- Assign the access port or SSID to the correct VLAN.
- Use a test client to check DHCP, gateway and DNS.
- Test one permitted internal connection and one deliberately prohibited connection.
- Check internet access and confirm the expected firewall Rule ID in Log Viewer.
NAT is normally not required for internal traffic. If the client receives an address but cannot reach the firewall as a DNS server or by ping, check Device Access first. The full procedure, including switch tagging and DHCP, is described in Set up and test a Sophos Firewall VLAN.
Sophos does not specify a fixed maximum number of VLANs per physical parent port for XGS appliances. Even so, multiple uplinks or a LAG can simplify operations and troubleshooting under high load, with many VLANs or in HA designs.
Choose the correct interface type
Alias
An alias adds another IP address to an existing interface. This is particularly useful when a provider supplies multiple public IP addresses in the same subnet.
Multiple separate WAN interfaces in the same subnet can cause ARP problems and unreachable gateways. In this case, an alias on the existing WAN interface or a properly designed LAG is usually the cleaner solution. An alias follows the state of its parent interface and cannot be disabled independently.
Bridge
A bridge connects multiple interfaces at Layer 2. It can operate with an IP address for routed traffic or transparently without an IP address. VLANs are usually clearer for new segmented networks; bridges are more appropriate for migrations or deliberately transparent designs.
Important restrictions apply:
- A bridge does not support Dynamic DNS, DHCP client, PPPoE or IPsec VPN.
- Traffic between bridge members may still require firewall rules, such as a LAN-to-LAN rule.
- HA cannot be enabled while STP is active on a bridge.
- If a VLAN filter is enabled but no VLAN is permitted, the firewall drops all tagged frames; untagged traffic remains unaffected.
- Traffic over a bridge without an IP address can be dropped without a log entry if it matches a web proxy rule or NAT rule.
For a transparent bridge, check whether Web Proxy Filtering or Source Translation is actually required.
The Sophos Known Issues List also describes a build-specific defect for SFOS 22.0 GA Build 411 and MR1 Build 490: If traffic over a bridge is translated with SNAT or MASQ and both source and destination are behind the same physical bridge member, reply packets can be dropped by the hairpin filter without appearing in drppkt. This also applies when only one bridge member is actively used. Traffic across different physical members or without SNAT/MASQ is not affected. Newer builds such as 22.0 MR2 Build 546 are not listed as affected in the current Known Issues List.
If only certain bridge connections fail, check the topology and NAT together, temporarily test without Source Translation or use a routed design. The separate SFOS 22 issue affecting VLAN traffic to the firewall is described in Check bridge VLANs after SFOS 22.
A bridge over RED can extend a Layer 2 network across locations, but it should remain a justified exception.

Broadcasts, ARP and unknown unicast traffic then traverse the WAN connection. A routed design with dedicated site subnets and specific firewall rules is more stable, scalable and easier to troubleshoot.
LAG
A Link Aggregation Group combines two to four physical interfaces into one logical uplink. VLANs can then be configured on top of it.

The common operating modes are:
- Active-Backup: One link is active and another takes over if it fails.
- LACP (802.3ad): Multiple links can be used in parallel; the firewall and switch must have matching configurations.
Eligible members are unbound physical interfaces with static configurations. PPPoE, Cellular WAN and wireless interfaces are excluded. With LACP, all ports must have the same type and speed.
The xmit-hash-policy distributes connections across the links. It does not normally make a single TCP connection faster because that connection remains on one link. The main benefits of LAG are redundancy and additional aggregate bandwidth for multiple parallel connections.
XFRM for route-based IPsec
For a route-based IPsec connection, SFOS automatically creates an XFRM interface in the VPN zone. This applies both to Any-to-any connections and to connections with Traffic Selectors:
- Any-to-any: Assign an IP address to the automatically created XFRM under Network > Interfaces. Static, SD-WAN or dynamic routes then determine the tunnel traffic.
- Traffic Selectors: SFOS creates the XFRM and automatically adds a static route when the tunnel is established. You cannot assign an IP address or add a route to this XFRM.
In both cases, VPN traffic requires suitable firewall rules. Under Administration > Device access, enabling IPsec for the WAN zone permits incoming IPsec connection requests. Ping through the tunnel is enabled separately for VPN.
An XFRM interface is not disabled directly under Network > Interfaces, but through its connection under Site-to-site VPN > IPsec. MTU and MSS are relevant when diagnosing fragmentation issues; Check MTU and MSS for VPN problems explains the procedure.
RED
A RED interface connects a branch office through an encrypted tunnel. The operating mode determines how much traffic passes through the central firewall:
- Standard/Unified: The central firewall manages and filters all site traffic. If the tunnel fails, internet access may also fail.
- Standard/Split: Only specified destination networks use the tunnel; internet traffic exits locally and is not centrally filtered.
- Transparent/Split: The RED operates transparently within an existing network. This is flexible, but harder to plan and troubleshoot.
- Manual/Split: The network configuration is more manual and can allow greater local autonomy.
The RED service must be enabled under System services > RED. The connection typically requires TCP 3400, UDP 3410 and NTP over UDP 123. DNS, correct system time and outbound internet access must work.
VLAN behavior depends on the RED model, operating mode, LAN port mode and wireless configuration. Sophos recommends Standard/Unified when VLANs are used behind the RED; on an SD-RED 60, VLAN tagging is only available in this mode. Wireless networks using Bridge to VLAN follow separate rules. Set up Sophos SD-RED explains mode selection, provisioning, LED status and troubleshooting.
Check status and Device Access
Interface status
Under Network > Interfaces, the status values indicate whether to investigate the link or the policy first:
Not configured: no zone assignedConnected: configured and connectedConnecting: currently obtaining an address, for example through DHCPDisconnected: address has been releasedDisconnecting: address is being releasedUnplugged: no physical connection; for WiFi, there may be no access point or wireless networkNot available: configured FleXi Port without an installed FleXi Port module
For Not configured or Unplugged, firewall rules are not the first place to look. First check zone binding, the cable, SFP, port speed, switch port and DHCP or PPPoE.
Local firewall services
Under Administration > Device access, specify for each zone whether local services such as HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO or Wireless Protection can be reached.
These permissions apply to the firewall itself. Transit traffic between networks is controlled by firewall rules. HTTPS and SSH should only be allowed from a management network or through a targeted Local service ACL exception rule. DNS is required when clients use the firewall as their DNS server.
⚠️ If clients are allowed to use the firewall’s web proxy, SFOS treats HTTP and HTTPS requests as internal proxy requests. WebAdmin, Captive Portal, VPN Portal or User Portal may therefore be reachable even when the corresponding service is disabled for the client zone. In this design, proxy access and local portals must be checked separately.
Handle dependencies and changes safely
Check Object Usage before editing or deleting
Zone binding, DNS, gateways, SD-WAN, interface hosts, VLANs, Dynamic DNS, DHCP, firewall rules, NAT and VPN can all depend on the same interface. Object usage shows these references.
The displayed counter is automatically updated only once per day. Before making a change or deleting an interface, select Refresh and document the important dependencies.
Disabling an interface preserves its configuration. IPsec tunnels for which the firewall is the initiator are disconnected immediately. Responder tunnels and remote access connections end no later than their inactivity timeout or Dead Peer Detection.
When deleting a virtual interface, SFOS can remove dependent firewall rules, DHCP configurations, ARP entries, routes, interface hosts and other references. Alias interfaces follow their parent; XFRM interfaces are managed through the IPsec connection.
HA and remote changes
Dedicated HA link interfaces belong in a DMZ zone. Other monitored interfaces or interfaces used for administration can belong to other zones.
Active-active HA requires statically configured interfaces. Cellular WAN is disabled for HA. Active-passive can use dynamically addressed WAN interfaces, but connections such as PPPoE do not necessarily preserve their session during failover.
Before making a production change:
- Document the configuration and dependencies.
- Prepare a maintenance window, rollback time, backup and specific rollback path.
- Test an independent administration path, such as Sophos Central, a second WAN connection, a separate management network or a person on site.
- Prepare a test client or uniquely identifiable test traffic, then add and test the new zone or path.
- Check the link, IP address, gateway, DHCP, DNS, firewall rules, NAT and Device Access.
- Delete old objects only after the new path is stable.
For a VLAN trunk, the rollback plan must include the previous VLAN ID, native VLAN and switch port profile. For WAN changes, include the provider settings and SD-WAN routes; for XFRM, also include the tunnel, routing and firewall rules in both directions.
Troubleshoot systematically
The symptom usually indicates where to start:
- Interface is unbound or disabled: Check zone binding and status. A physical port is not deleted; its configuration can be removed by setting the zone to
None. - VLAN does not work: Compare the VLAN ID, parent interface, trunk, tagged/untagged settings and native VLAN.
- Firewall cannot be reached through ping, HTTPS or DNS: Check Device Access and Local Service ACL, not a normal firewall rule first.
- Internal traffic is blocked: Check the source zone, destination zone, network objects, routing, services and rule order.
- WAN gateway remains inactive: Check the link, IP address, gateway, PPPoE credentials and WAN Link Manager.
- Multiple WAN ports are in the same subnet: Avoid ARP problems and consider an alias or LAG.
- SFP or port speed does not match: Compare the transceiver, cable, breakout configuration and speed on both sides.
- VPN or PPPoE is unstable: Check MTU and MSS.
For the actual investigation, use this order:
- Network > Interfaces: link, IP address, zone and gateway
- Network > Zones: zone type and Device Access
- Hosts and services: network and service objects
- Firewall rules: direction, order, services and logging
- NAT rules: original and translation
- Log viewer: Rule ID or drop reason
- Diagnostics > Tools > Packet capture: packet arrival and forwarding
If the rule looks correct but does not match, see Firewall rule does not match. Use Packet Capture in WebAdmin explains how to trace the packet flow.
Operations checklist
- zones planned and documented by trust level
- zone, interface and network object not confused with each other
- VLAN ID, parent, trunk and gateway checked
- Device Access restricted, particularly for HTTPS, SSH, DNS, ping and portals
- firewall rules created with specific zones, networks, services and logging
- alias considered for additional provider IP addresses in the same subnet
- DHCP, DNS, NTP, routing and, where applicable, NAT tested
- Object Usage refreshed and checked before changes
- independent administration path and rollback route prepared
- link status, Log Viewer and Packet Capture checked after the change