Configure Sophos Firewall zones and interfaces

Zones and interfaces are among the most important basics of a Sophos Firewall. If they are planned properly, firewall rules, NAT, VPN, Web Protection and troubleshooting become much easier later. If they are clicked together too quickly, the result is often an environment where rules become confusing or management services are reachable from the wrong places.

A zone is a logical security group. An interface is a physical or virtual connection, for example Port1, a VLAN, a bridge, a LAG, an alias, a RED interface or an XFRM interface for route-based VPN. Every interface is assigned to exactly one zone. Firewall rules later rely heavily on these zones, so the zone structure should be planned from a security perspective, not only from a technical one.

Why zones matter

Zones on Sophos Firewall are more than a visual grouping. They define security areas and are used in several places:

• Firewall rules use Source zone and Destination zone.
• Device Access controls which local firewall services are reachable per zone.
• NAT, SD-WAN, VPN, Web Protection and logs are easier to understand with clean zones.
• Troubleshooting becomes clearer because it is immediately visible which security area a packet comes from and where it should go.

Good zoning does not automatically prevent every mistake, but it forces clear boundaries. A client network, server network, guest WiFi and DMZ should not simply all be treated as LAN if they have different risks and rules. Otherwise, large allow rules, unclear exceptions and unnecessary management access often appear later.

Good zones always answer this question: Which networks have the same trust level and should be treated in a similar way? If two networks need different access rights, logging requirements or management access, a dedicated zone or at least a very deliberate rule concept is useful.

Understand standard zones

Sophos Firewall includes several standard zones:

You find the standard zones under Network > Zones. Custom zones can be created as type LAN or DMZ. Additional WAN or VPN zones cannot simply be created freely because these zone types have special firewall functions.

Important: A zone is not an automatic allow rule. Even between two interfaces in the same zone, suitable firewall rules are required depending on direction and scenario. Sophos explicitly notes that traffic between two LAN zone interfaces is not automatically allowed and requires a suitable LAN-to-LAN rule.

Plan zones before creating them

Before creating zones, note which networks have different security requirements. Typical examples are:

• workplace LAN
• server network
• management network
• DMZ
• guest WiFi
• VoIP
• camera or IoT network
• production network
• VPN clients
• MPLS or site connections

A dedicated zone makes sense when a network needs its own rules, its own Device Access or a different trust level. Several VLANs can also be in the same zone if they should be treated identically. Too many zones do not automatically make a configuration more secure. They only help when there are clear rules behind them.

For many small and medium-sized environments, this basic structure is a good starting point:

Not every VLAN automatically needs its own zone. If several client VLANs receive exactly the same firewall rules, the same web policy and the same Device Access, they can remain in one shared client zone. But if one VLAN may reach servers, another only the internet and a third must not access local firewall services at all, the separation should be modelled deliberately.

A good pattern is:

Create a new zone

Open Network > Zones and click Add.

1. Enter a short, clear name, for example Server, Guest, Management or MPLS.
2. Select LAN or DMZ as the type.
3. Under Device Access, deliberately define which local firewall services should be reachable from this zone.
4. Save the configuration.

LAN or DMZ as zone type?

For custom zones, Sophos Firewall usually lets you choose between LAN and DMZ. Both types group interfaces so they can be used cleanly later in rules, Device Access and policies. The difference is mainly the security idea behind the zone.

Use LAN for internal, generally trusted networks. Examples include client networks, internal server networks, management networks, VoIP, printers or internal VLANs. Even with a LAN zone, traffic between interfaces is not automatically allowed. If two LAN zones or two interfaces inside a LAN zone should communicate, suitable firewall rules are required.

Use DMZ for networks with higher risk or clear isolation. Typical examples are public web servers, reverse proxies, mail gateways, jump hosts or systems that must be reachable from several security areas. A DMZ should be planned so that it only receives the necessary connections into internal networks. If a server in the DMZ is compromised, that must not automatically create broad access to the internal LAN.

As a simple rule of thumb:

HA interfaces also belong in a DMZ zone. For normal admin or client networks, LAN is usually the more suitable type.

For an internal admin network, HTTPS can make sense. For normal client or guest networks, management access should be avoided. Ping/ping6 is often helpful for troubleshooting, but should be enabled deliberately. DNS is only required if clients in this zone use the firewall as DNS server.

⚠️ Device Access is not the same as a firewall rule. Access to local firewall services such as WebAdmin, SSH, User Portal, DNS or Ping is controlled through Administration > Device access and local ACL exceptions.

Configure an interface

Interfaces are found under Network > Interfaces. A physical port can be used as LAN, WAN or DMZ, for example. Virtual interfaces such as VLAN, Bridge, LAG, RED or XFRM are added separately.

For a physical interface, these points are especially important:

Only interfaces in the WAN zone receive gateway configuration. Internal interfaces are usually configured statically. For provider connections, DHCP or PPPoE can make sense.

Descriptive names are important. PortD says little six months later. Server VLAN, MPLS Provider, Guest WiFi or Core Switch Trunk help much more in daily operations.

Create a VLAN interface

Create a VLAN interface under Network > Interfaces > Add interface > Add VLAN. The most important fields are Parent Interface, Zone, VLAN ID and IP configuration.

The Parent Interface is the physical port or LAG where the tagged VLAN arrives. If the switch sends the VLAN on another port, untagged or with the wrong VLAN ID, the firewall may still show a VLAN interface, but clients will not reach it reliably.

For internal VLANs, a static IP address on the firewall is usually used, for example as the default gateway for this VLAN. The zone later decides which firewall rules, web policies and Device Access settings apply. That is why one should not only enter the IP address when creating a VLAN, but also decide whether the VLAN belongs to Client, Server, Management, Guest, DMZ or another zone.

Read interface status correctly

Under Network > Interfaces, Sophos Firewall shows status messages. These status messages are very useful for troubleshooting because they quickly show whether an interface is only misconfigured or whether there is really no link.

If an interface unexpectedly shows Not configured or Unplugged, do not start by looking at firewall rules. First check zone binding, link, SFP/transceiver, cable, switch port and, with DHCP/PPPoE, address assignment.

Classify VLAN, Bridge, LAG, Alias and RED

Sophos Firewall supports different interface types. For beginners, the most important point is when each type is useful.

For new installations, VLANs on a clearly defined uplink to the switch are usually cleaner than a large bridge across many ports. A bridge can be practical for migrations or very simple setups because several ports are treated like one shared Layer 2 segment. But that is exactly the disadvantage: security boundaries, broadcast domains and error sources become less visible.

We therefore recommend bridges only for targeted scenarios and not as the default design. In practice, bridges have several disadvantages:

• Several ports share the same Layer 2 segment, so broadcasts and faults can affect more devices.
• Firewall rules become less clear because separation is no longer visible through dedicated interfaces, VLANs and zones.
• Troubleshooting becomes harder because packet flow, MAC learning, STP topics and switch configuration must be considered together.
• Later segmentation becomes more complex if a simple bridge later has to become separate client, server, guest or management networks.
• HA, VLAN, DHCP or Device Access designs quickly become confusing if too many functions run through a bridge.

Bridges on Sophos Firewall can be created over physical interfaces, RED interfaces, VLANs or LAGs. They can be operated with or without their own IP address. This is where misunderstandings often start:

• Without an IP address, the bridge works transparently but cannot be used like a normal routed interface.
• If routing is required on a bridge, the bridge must have an IP address.
• Traffic between bridge members still requires suitable firewall rules between the involved zones, for example LAN to LAN.
• STP can be useful when redundant paths exist and bridge loops must be prevented.
• VLAN filters and EtherType filters can help limit Layer 2 traffic passing through a bridge.
• Sophos notes that traffic over bridge interfaces without an IP address can be dropped if it hits a firewall rule with Web Proxy Filtering or a NAT rule. Such drops are not logged. With NAT, special attention must be paid to Source Translation or Override Source Translation.

This last point is important: If traffic over a bridge does not work and no logs appear, the problem is not always the Log Viewer. It can be the bridge mode, NAT or Web Proxy Filtering.

If VLANs already exist on the switch, the firewall should deliberately take these VLANs over as dedicated VLAN interfaces. This results in clearer zones, cleaner firewall rules and better long-term maintainability.

RED Bridge: stretching a network across sites

It is technically possible to add RED interfaces to a bridge and stretch a Layer 2 network across several sites. This can help in special cases, for example when an application must remain in the same subnet or a migration should happen without immediate IP changes.

We would recommend this design only very cautiously. A bridge over RED extends the Layer 2 domain across the tunnel. Broadcasts, ARP, unknown unicast packets and other Layer 2 effects then travel over a WAN or internet connection. This can reduce performance and make faults harder to understand. If the RED tunnel is unstable, the stretched network is affected directly.

In most cases, a routed design is better: each site has its own subnets, the firewall routes between the networks and firewall rules define exactly what is allowed. This is cleaner, more scalable and much easier to troubleshoot.

LAG: plan redundancy and bandwidth properly

A Link Aggregation Group (LAG) combines several physical ports into one logical interface. This is useful when redundancy to the core switch is required or more bandwidth between firewall and switch should be provided. LAG does not replace clean zoning. The LAG interface is still just one interface on which VLANs can be operated or a zone can be assigned.

Sophos Firewall mainly supports two common operating modes:

Important: LACP only works cleanly when the other side is configured correctly. On the switch, the ports must be in the same LAG group, use the same speed and duplex mode and match the firewall configuration. If a LAG is created only on the firewall but not on the switch, hard-to-understand packet loss or asymmetric connection problems often appear.

There are some practical limits for LAGs:

• A LAG on Sophos Firewall consists of two to four physical interfaces.
• Only unbound physical interfaces with static configuration can be used as members.
• PPPoE, Cellular WAN and WLAN interfaces cannot be used as LAG members.
• With LACP (802.3ad), member ports must have the same type and speed.
• The xmit-hash-policy defines how sessions are distributed across links. A single TCP session usually does not suddenly become faster because it usually remains on one link.

For small environments, one clean trunk port is often enough. LAG becomes useful when the core switch should be connected redundantly, many VLANs run over the same uplink or the firewall really needs more throughput to the switch.

XFRM: understand route-based IPsec as an interface

An XFRM interface belongs to route-based IPsec VPN. It is not planned like a normal VLAN or physical port, but is created in the context of an IPsec connection. Sophos Firewall automatically creates an XFRM interface when both the local and remote subnets in an IPsec connection are set to Any.

This is an important difference from classic policy-based IPsec tunnels. With route-based VPN, not only the IPsec policy matters, but also routing, firewall rules and the XFRM interface. This makes more complex site connections more flexible, but requires clean planning:

• The XFRM interface is in the VPN zone.
• Under Administration > Device access, IPsec must be allowed for the WAN zone so the connection can be established.
• If local or remote subnets are not Any, no XFRM interface is created.
• MTU and MSS are especially important for route-based VPN because IPsec adds overhead.
• An XFRM interface is not disabled directly under Network > Interfaces, but through the related IPsec connection under Site-to-site VPN > IPsec.

For admins, XFRM is especially relevant when SD-WAN routing, dynamic routing or several networks over a site tunnel should be controlled cleanly. If only a very simple Site-to-Site connection with two fixed networks is needed, a classic policy-based tunnel is often easier to understand.

RED: branch offices as their own interface concept

RED interfaces are not normal switch ports. RED stands for Remote Ethernet Device and is used to connect a branch office to the Sophos Firewall through an encrypted tunnel. This can be implemented with dedicated SD-RED hardware or firewall-to-firewall RED connections.

Before planning, it should be clear which operating mode is required:

For many companies, Standard/Unified is the cleanest option when the site should be fully protected by the central firewall. The disadvantage is clear: if the RED tunnel fails, the site may also lose centrally controlled internet access depending on the design. Standard/Split reduces this dependency, but it also means local internet traffic is no longer fully filtered and logged by the central Sophos Firewall.

Check these points early with RED:

• The RED service must be enabled under System services > RED.
• The connection typically requires TCP 3400, UDP 3410 and NTP 123.
• SD-RED devices need correct time, otherwise TLS handshake and tunnel establishment can fail.
• During initial deployment, DHCP on the uplink is usually easier because the device must reach provisioning.
• VLANs are not equally useful in every RED mode. Standard/Split and Transparent/Split are not intended for VLAN-tagged frames. If VLANs are required behind an SD-RED, choose the operating mode very carefully.
• If a RED device is behind a provider router, outbound connections and DNS/NTP must work.

RED is very practical for small sites, but it should not be treated like a normal LAN cable. The key decision is whether the site should be centrally protected, locally autonomous or only partially connected through the tunnel. This decision affects DHCP, DNS, VLANs, routing, firewall rules, logging and troubleshooting.

Restrict Device Access cleanly

Under Administration > Device access, you can see which local firewall services are reachable from which zones. These include:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

For production environments, the fewer local services are reachable from a zone, the better. Especially HTTPS and SSH should only be allowed from trusted management networks or through a Local service ACL exception rule.

If SSH is required, this guide helps: Connect to Sophos Firewall with SSH.

Keep dependencies in mind

Interface changes are rarely isolated. Sophos points out that interface changes can affect dependent configurations, for example:

• Zone Binding
• DNS
• gateways
• SD-WAN routes
• interface-based hosts
• VLAN interfaces
• Dynamic DNS
• firewall rules
• NAT rules

Before larger changes, check Object usage to see where an interface, zone or host object is already used. Sophos Firewall shows object usage and links directly to many dependent configurations.

Be especially careful when disabling or deleting:

• If an interface is disabled, the configuration remains and the status is still visible.
• Site-to-site IPsec tunnels where the firewall is the initiator are disconnected immediately.
• Site-to-site IPsec tunnels as responder and Remote Access connections disconnect through inactivity or Dead Peer Detection at the latest.
• Alias and XFRM interfaces cannot be disabled directly like normal interfaces. Alias interfaces follow the physical interface, XFRM interfaces are disabled through Site-to-site VPN > IPsec.
• If a virtual interface is deleted, dependent firewall rules, DHCP configurations, ARP entries, routes, interface hosts and further references can be removed as well.

Therefore always check before deleting whether the interface is used in firewall rules, NAT rules, DHCP, routing, SD-WAN, Dynamic DNS or host objects. A careless delete can remove more than just the interface itself.

Common pitfalls

Interface is unbound or disabled: Check whether a zone is assigned. A physical interface cannot be deleted, but its configuration can be removed by setting the zone to None.

VLAN does not work: Check VLAN ID, switch port, tagged/untagged configuration, native VLAN and whether the VLAN was created on the correct parent interface.

Clients cannot reach the firewall by Ping or HTTPS: Do not first check normal firewall rules. Check Administration > Device access and local ACL exceptions.

Traffic between two internal networks does not work: Check Source zone, Destination zone, network objects, routing and the position of the firewall rule.

WAN gateway does not become active: Check IP configuration, gateway IP, link status, PPPoE credentials, DNS and, if needed, WAN link manager.

Several WAN interfaces in the same subnet: If several WAN interfaces use IP addresses from the same subnet, ARP problems can occur and gateways may become unreachable. If a provider supplies several public IPs in the same subnet, alias or LAG interfaces are usually cleaner than several separate WAN interfaces in the same network.

SFP, port speed or breakout does not match: The port speed on switch, router, transceiver and firewall must match. A 25 Gbit/s port cannot be connected directly to a 40 Gbit/s port without suitable technology. On models with 40G or 100G ports, breakout cables can be relevant when one port should be split into several smaller ports.

MTU problems with VPN or PPPoE: Check MTU and MSS. With VPN traffic, an MTU value that is too high can cause packet loss that looks like random connection problems in daily use.

Troubleshooting

This order is practical for troubleshooting:

1. Network > Interfaces: Check link status, IP address, zone and gateway.
2. Network > Zones: Check Device Access and zone type.
3. Hosts and services: Check whether host and service objects are correct.
4. Rules and policies > Firewall rules: Check Source zone, Destination zone, services and order.
5. Rules and policies > NAT rules: If NAT is involved, compare Original and Translated carefully.
6. Log viewer: Check which rule or drop is applied.
7. Diagnostics > Tools > Packet capture: Check whether packets arrive at all and where they are forwarded.

When zones and interfaces are clean, the next step becomes much easier: Understand and configure Sophos Firewall rules correctly. If traffic does not work despite apparently correct zones, use the checklist Firewall rule not matching: check order, matching and logs. For deeper analysis, you can also use Packet Capture in WebAdmin and, for translations or port forwarding, refer to Understand NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Further information

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface