Skip to content
Avanet

Sophos Firewall Configure zones and interfaces

Sophos Firewall

Zones and interfaces are among the most important fundamentals of a Sophos Firewall. If you plan them carefully, you will make later firewall rules, NAT, VPN, web protection and troubleshooting much easier. If you click them together too quickly, you often create an environment in which rules become confusing or management services are accessible in 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. Each interface is assigned to exactly one zone. Firewall rules will later work heavily with these zones, so the zone structure should not only be planned technically, but also in terms of security.

Which network design article fits?

Zones and interfaces are often the starting point, but not always the actual goal of the configuration. Depending on the task, a more specific article fits better:

This separation prevents typical design errors. A zone does not replace a firewall rule, a VLAN does not replace a security concept, and Device Access is not the same as normal traffic between two networks. First, it should be clear which security areas exist. Interfaces, VLANs, rules, NAT, DNS and management access are then built accordingly.

Why zones are important

Zones on the Sophos Firewall are more than just a visual grouping. This defines security areas that are used in several places:

  • Firewall rules work with Source zone and Destination zone.
  • Device Access controls which local firewall services are accessible per zone.
  • NAT, SD-WAN, VPN, web protection and logs are made easier to understand through clean zones.
  • Troubleshooting becomes clearer because you can immediately see which security area a package is coming from and where it is supposed to go.

Good zoning does not automatically prevent every error, but it does force clear boundaries. A client network, a server network, a guest WiFi, and a DMZ should not all simply be treated as a “LAN” if they have different risks and rules. Otherwise, large allow rules, unclear exceptions and unnecessarily open management access will arise later.

Good zones always answer this question: Which networks have the same trust level and can be treated similarly? If two networks need different access rights, logging requirements or management access, a separate zone or at least a very conscious rule concept makes sense.

It is important to separate zone and network object. The zone describes through which security area a packet enters the firewall or where it should go. The network object describes the specific IP source or target. A rule is only clean when both are correct: Source zone must not just be broadly called LAN while Source networks and devices remains set to Any. Conversely, a correct network object helps little if the traffic enters through a different zone than expected.

Understand standard zones

Sophos Firewall comes with several standard zones:

  • LAN: Internal networks, clients, servers and management networks.
  • WAN: Internet uplinks, provider routers, PPPoE, DHCP or static WAN addresses.
  • DMZ: Publicly accessible servers, reverse proxies and isolated services.
  • WiFi: Wi-Fi networks, Sophos Access Points and wireless segments.
  • VPN: Remote Access VPN, site-to-site VPN and other tunnel contexts.

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

Important: A zone is not an automatic permission. Depending on the direction and scenario, appropriate firewall rules are also required between two interfaces in the same zone. Traffic between two LAN zone interfaces is not automatically allowed, but requires a suitable LAN-to-LAN rule.

Sophos Firewall supports custom zones, but not as an unlimited substitute for clean rules. The official limit is a maximum of 100 zones. In practice, this limit should not be exhausted. If almost every VLAN gets its own zone even though many of them need identical rules and the same Device Access, the rulebase often becomes harder to maintain, not safer.

Plan zones before creation

Before setting up, you should note which networks have different security requirements. Typical examples:

  • Workplace LAN
  • Server network
  • Management network
  • DMZ
  • Guest WiFi
  • VoIP
  • Camera or IoT network
  • Production network
  • VPN clients
  • MPLS or location connections

A separate zone makes sense if a network needs its own rules, its own Device Access or another level of trust. However, several VLANs can also be in the same zone if they are to be treated equally. Too many zones does not automatically make a configuration more secure. Zones are only helpful if there are clear rules behind them.

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

  • LAN or Client: normal workstation clients.
  • Server: internal servers, NAS, application servers and domain controllers.
  • Management: Admin PCs, monitoring, backup, switch and firewall management.
  • Guest or WiFi: Guest WiFi or BYOD networks with limited access.
  • DMZ: Systems that must be accessible from the Internet or from multiple networks.
  • WAN: Internet and provider connections.
  • VPN: Remote Access VPN or site-to-site VPN contexts.

Not every VLAN automatically needs its own zone. If multiple client VLANs get exactly the same firewall rules, web policy and Device Access, they can stay in a common client zone. However, if one VLAN is allowed to reach servers, another is only allowed to access the Internet, and a third is not supposed to have access to local firewall services at all, the separation should be modeled consciously.

A good pattern is:

  • Other trust level: Check your own zone.
  • Own management access to the firewall: check your own zone or your own ACL rule.
  • Other logging or other protection functions: own zone can be useful.
  • Only different IP range, but same security policy: common zone concept can be enough.

Translate zone model into an access matrix

After zone planning, you should briefly determine which zone is allowed to talk to which other zone. This access matrix is ​​often more helpful than immediately creating rules in WebAdmin because it makes contradictions visible.

A simple example:

  • Client to WAN: Allowed for Web, DNS, NTP and required applications.
  • Client to Server: Only defined application ports, not Any.
  • Guest to WAN: Allowed, mostly with web policy and logging.
  • Guest to Server: Normally blocked.
  • IoT to Server: Only to precisely defined services, for example MQTT, DNS or NTP.
  • Management to LAN, Server, DMZ: Administrative access, tight and logged.
  • DMZ to LAN: Blocked by default, only allow explicit return connections.
  • VPN to Server: Only required internal targets and services.

The matrix does not have to be large. What is important is that every permitted direction has a purpose. If an entry cannot be explained, it should not arise as a broad firewall rule.

For each line you should also note:

  • required services and ports
  • whether user or group matching is necessary
  • whether NAT is involved
  • whether logging should remain permanently active
  • which security features are suitable, for example IPS, Web Policy or Application Control
  • who is technically responsible for access

The actual firewall rules are then created from this matrix. The detailed options and typical errors for rule order, source, destination, NAT and logging are described in Understand and correctly configure Sophos Firewall rules.

Planning check before changes

Before zones or interfaces are created, moved or deleted, the dependencies should be clarified in writing. Many later errors are not caused by the IP address itself, but by forgotten firewall rules, NAT rules, DHCP servers, Device Access or routing decisions.

For each new zone or interface, at least these questions should be answered:

  • Trust level of the network: The zone, firewall rules and Device Access depend on this.
  • Users and systems on the network: Clients, servers, guests, IoT, VoIP and management need different rules.
  • Default Gateway: The firewall is often the gateway for VLANs, but sometimes not for migrations.
  • DHCP source: Sophos Firewall, internal DHCP server or DHCP relay must be deliberately planned.
  • DNS Server: DNS affects web filtering, name resolution and troubleshooting.
  • Local firewall services: Device Access for DNS, Ping, HTTPS, SSH or portals must match.
  • Rules and NAT paths: Without appropriate firewall and NAT rules, the interface is only technically available.
  • Test flow: A test client, a test target and an expected log entry save a lot of search time.

A current backup should also be available for productive changes. If interfaces are already in use, Object usage is mandatory before changing name, zone binding, IP address or interface type.

Create new zone

Open Network > Zones and click on Add.

Sophos Firewall Add zone mask with LAN and DMZ type as well as Device Access options
When creating a zone, you select the LAN or DMZ type and directly specify which local firewall services can be reached from this zone.
  1. Assign a short, unique name, for example Server, Guest, Management or MPLS.
  2. Select LAN or DMZ as type.
  3. Under Device Access, consciously specify which local firewall services may be accessible from this zone.
  4. Save.

After saving, the zone should be checked directly in two places: under Network > Zones for name, type and Device Access, and later in a test firewall rule as a selectable Source zone or Destination zone. If the zone exists but no interface is assigned to it, no production traffic will use it yet.

LAN or DMZ as zone type?

For your own zones you can usually choose between LAN and DMZ on the Sophos Firewall. Both types group interfaces so that they can later be used cleanly in rules, Device Access and policies. The difference lies primarily in the security idea behind the zone.

LAN is used for internal, fundamentally trustworthy networks. These include, for example, client networks, internal server networks, management networks, VoIP, printers or internal VLANs. The same applies to a LAN zone: Traffic between interfaces is not automatically permitted. If two LAN zones or two interfaces within a LAN zone are to talk to each other, appropriate firewall rules are required.DMZ is used for networks with higher risk or clear isolation. Typical examples are publicly accessible web servers, reverse proxies, mail gateways, jump hosts or systems that must be accessible from multiple security areas. A DMZ should be planned so that it only receives the necessary internal connections. If a compromised server is in the DMZ, this should not automatically result in widespread access to the internal LAN.

As a simple rule of thumb:

  • LAN: internal networks that are generally trusted and that communicate primarily outbound or internally.
  • DMZ: exposed or particularly isolated networks where internal access should be strictly limited.

HA interfaces also belong in a DMZ zone. For normal admin or client networks, LAN is usually the more suitable type.HTTPS can be useful for an internal admin network. For normal client or guest networks, management access should be avoided. Ping/ping6 is often helpful for troubleshooting, but should be activated consciously. DNS is only needed if clients in this zone use the firewall as a DNS server.

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

Configure interface

Interfaces can be found under Network > Interfaces. For example, a physical port can be operated as a LAN, WAN or DMZ. Virtual interfaces such as VLAN, Bridge, LAG, RED or XFRM are also created.

Sophos Firewall Network Interfaces Overview with physical ports, VLANs, LAG, RED and wireless protection interfaces
In the interface overview you can see physical ports, VLANs, LAGs, RED interfaces, zones, IP addresses, status and usage in one place.

These points are particularly important for a physical interface:

  • Name: descriptive name for later rules and logs.
  • Hardware: physical port, for example Port1, Port2 or PortA.
  • Network zone: Security zone in which the interface is located.
  • IPv4 configuration: Static, DHCP or PPPoE.
  • IPv6 configuration: Static, DHCP or Delegated, depending on the environment.
  • Gateway: only relevant for WAN interfaces.
  • MTU / MSS: important for PPPoE, VPN, SD-WAN and fragmentation issues.

Only interfaces in the WAN zone receive a gateway configuration. Internal interfaces are usually addressed statically. DHCP or PPPoE can be useful for provider connections.

If the provider provides IPv6 via prefix delegation, you should plan the restrictions and the process separately. The practical article for this is Configure IPv6 Prefix Delegation to Sophos Firewall.

Meaningful names are important. PortD means little in six months. Server VLAN, MPLS Provider, Guest WiFi or Core Switch Trunk help significantly more during operation.

Edit an existing physical interface like this:

  1. Open Network > Interfaces.
  2. Open the menu for the required port and select Edit interface.
  3. Check Name, Network zone, IP configuration, gateway and MTU/MSS.
  4. For WAN interfaces, also check gateway name and gateway IP.
  5. Save, then check link status, gateway status and Log Viewer.

Before changing a production interface, Object usage should be opened. Interface changes can affect zone binding, DNS, gateways, SD-WAN routes, interface-based hosts, VLAN interfaces, Dynamic DNS, firewall rules and NAT. When deleting a virtual interface, Sophos can also remove dependent configuration such as firewall rules, DHCP or routing references. This is exactly where unpleasant outages happen if only the port name was considered.

Before firmware upgrades, make sure that interface names, hardware names and branch names do not end with a long block of numbers. A WebAdmin display error is documented in the SFOS release notes if such names end with ten or more digits, for example VLAN_1234567890. Check Sophos Firewall before SFOS 22 upgrade is suitable for upgrade planning and specific tests.

Create VLAN interface

For a focused process with parent interface, switch tagging, DHCP, Device Access, firewall rules and tests, Sophos Firewall Set up and test VLAN is suitable. The following section classifies VLANs within the larger interface and zone model.

A VLAN interface is created under Network > Interfaces > Add interface > Add VLAN. The parent interface, zone, VLAN ID and IP configuration are particularly important.

Sophos Firewall Add VLAN Mask with interface, zone, VLAN ID and IPv4 configuration
When creating a VLAN interface, the parent interface, zone, VLAN ID and IP address must exactly match the switch design.

The parent interface is the physical port or a LAG on which the VLAN arrives tagged. If the switch sends the VLAN on a different port, untagged or with an incorrect VLAN ID, the firewall sees a VLAN interface, but the clients cannot reach it reliably.

For internal VLANs, a static IP address is usually used on the firewall, for example as the default gateway for this VLAN. The zone later decides which firewall rules, web policies and Device Access settings apply. This is exactly why you should not just enter the IP address when creating a VLAN, but also consider directly whether the VLAN requires Client, Server, Management, Guest, DMZ or another zone.

A concrete practical example with switch port profiles, tagged/untagged behavior, DHCP and test sequence can be found in Configure VLAN on Sophos Firewall and UniFi Switch.

On XGS hardware, Sophos does not state a fixed hard number of VLAN interfaces per physical interface. However, that does not mean a single parent port is always the best operational choice. For performance, troubleshooting and maintainability, VLANs should be distributed sensibly across physical ports or LAGs, especially when many VLANs, high east-west load or HA designs are involved.

Clean VLAN rollout

A VLAN is only considered complete when not only the interface has been created, but also the switch, DHCP, DNS, firewall rules and logging all fit together. Especially with new networks, it’s easy to search in the wrong place: the firewall rule looks correct, but the switch sends untagged. Or the client gets an IP address, but Device Access does not allow DNS access to the firewall.

For each new VLAN, these points should be checked:

  • Firewall Interface: VLAN ID, Parent Interface, Zone, IP Address and Subnet Mask match the design.
  • Switch port: Uplink to the firewall is configured as a trunk and has the VLAN tagged.
  • Access port or SSID: Client port or WLAN SSID maps clients to the correct VLAN.
  • Gateway: The firewall IP in the VLAN is the expected default gateway or the routing is documented differently.
  • DHCP: DHCP server, DHCP relay or external DHCP server distributes correct IP, gateway, DNS and lease.
  • DNS: Clients can resolve internal and external names as planned.
  • Device Access: Only required local firewall services are allowed from the zone, for example DNS or Ping.
  • Firewall rule: Source zone, source network, destination zone, services and logging match the test flow.
  • NAT: Only active if traffic really needs to be translated. For normal internal traffic, NAT is usually wrong.
  • Test: Log Viewer shows the expected firewall Rule ID; if necessary, Packet Capture confirms the packet flow.

As an acceptance test, it is not enough that a client receives any IP address. A useful test consists of several steps: connect the client via DHCP, ping the gateway, check DNS, test a permitted internal connection, see that forbidden access is deliberately blocked and then check internet access. This way you can see whether VLAN, zone, Device Access, firewall rule and NAT really match.

If multiple VLANs are created at the same time, you should use a separate test client or at least one unique test IP for each VLAN. Otherwise Log Viewer and Packet Capture will become unnecessarily confusing. Test firewall rule with Log Viewer, Policy Test and Packet Capture is suitable for the actual packet flow check.

Read interface status correctly

Under Network > Interfaces, the Sophos Firewall displays status messages. These status messages are very helpful when troubleshooting because you can quickly see whether an interface is just configured incorrectly or whether there really is no link.

  • Not configured: The interface is not assigned to a zone. So it can’t be used in any meaningful way until a zone has been bound.
  • Connected: The interface is configured and connected.
  • Connecting: A new IP address is currently being obtained, for example via DHCP.
  • Disconnected: The IP address has been released.
  • Disconnecting: The IP address is currently being released.
  • Unplugged: There is no physical connection. For WiFi it can also mean that no Access Point is connected or no wireless network is assigned.
  • Not available: FleXi ports have been configured, but the corresponding FleXi port module is no longer present.

If an interface unexpectedly shows Not configured or Unplugged, you should not search for firewall rules first. First you check the zone binding, link, SFP/transceiver, cable, switch port and, for DHCP/PPPoE, the address assignment.

Classify VLAN, Bridge, LAG, Alias and RED

Sophos Firewall supports different interface types. For beginners, the most important thing is when which type makes sense.

  • VLAN: ​​Standard for segmented networks on a trunk port.
  • Bridge: Transparent connection of multiple ports, often for simple setups or migrations.
  • LAG: Bundling multiple physical links for redundancy or bandwidth.
  • Alias: additional IP address on an existing interface.
  • RED: Remote Ethernet Device for external locations.
  • XFRM: Route-based IPsec VPN Interface.

Alias interfaces are often underestimated. They are particularly useful when a provider supplies several public IP addresses in the same subnet. Several separate WAN interfaces in the same subnet cause ARP problems on Sophos Firewall and can make gateways unreachable. In such designs, an alias on the existing WAN interface or a carefully planned LAG is usually the better choice.

For new installations, VLAN on a clearly defined uplink to the switch is usually cleaner than a large bridge over many ports. A bridge can be useful for migrations or very simple setups because multiple ports are treated as a common Layer 2 segment. But that is exactly the disadvantage: security boundaries, broadcast domains and sources of error become less clearly visible.

We therefore only recommend bridges specifically and not as a standard design. In practice, bridges have several disadvantages:

  • Multiple ports share the same Layer 2 segment, making broadcasts and interference more easily impact multiple devices.
  • Firewall rules are becoming less clear because the separation is no longer clearly visible across your own interfaces, VLANs and zones.
  • Troubleshooting becomes more difficult as packet flow, MAC learning, STP issues and switch configuration must be considered together.
  • Later segmentation becomes more complex if separate client, server, guest or management networks are to be created from a simple bridge.
  • HA, VLAN, DHCP or device access designs quickly become confusing if too many functions run over a bridge.

Bridges can be created on the Sophos Firewall via physical interfaces, RED interfaces, VLANs or LAGs and operated with or without their own IP address. This is exactly where misunderstandings often arise:

  • 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 be assigned an IP address.
  • For traffic between bridge members, appropriate firewall rules are still required between the zones involved, for example LAN to LAN.
  • STP can be useful if there are redundant paths and bridge loops should be prevented. However, STP cannot be enabled on bridge interfaces when HA is active.
  • VLAN filters and EtherType filters can help limit Layer 2 traffic passing through a bridge. If a VLAN filter is enabled but no permitted VLANs are entered, the firewall drops tagged traffic for all VLANs. Untagged traffic is not affected.
  • 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 you have to pay particular attention to the source translation or override source translation.

This last point is important: If you suddenly don’t see any logs over a bridge, even though traffic doesn’t seem to be working, the problem isn’t always with the Log Viewer. It could be due to the bridge mode, NAT or web proxy filtering.

If VLANs already exist on the switch, the firewall should consciously adopt these VLANs as its own VLAN interfaces. This results in clearer zones, cleaner firewall rules and is usually easier to maintain in the long term.

SFOS 22: Check bridge, SNAT and hairpin traffic

With SFOS 22 there is an additional bridge special case that is quickly overlooked in migrations. Routing over a bridge interface can fail if SNAT or MASQUERADE is applied to traffic over the bridge and the source and destination are reachable through the same physical bridge member. In this hairpin scenario, reply packets can be dropped on the bridge without the drop being cleanly visible in drppkt.

This is not a normal rule matching problem. If the Log Viewer shows little, the rule looks correct and still only certain connections over a bridge fail, you should check NAT and bridge topology together:

  • Is SNAT or MASQUERADE really needed on bridge traffic?
  • Do source and destination come via the same physical bridge member?
  • Is there only one actively used bridge member?
  • Would a routed design or a dedicated physical interface be cleaner?
  • Can traffic be tested without source translation?

There is also a separate SFOS 22 case for VLAN-tagged traffic to the firewall itself. The practical procedure is in Sophos Firewall Check bridge VLANs according to SFOS 22.

RED Bridge: Stretch network across locations

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

Sophos Firewall Bridge interface with RED bridge members and VLAN interfaces
A RED Bridge can stretch a network across locations, but should only be used very specifically due to performance, stability and troubleshooting.

We would only recommend this design very cautiously. A bridge over RED extends the Layer 2 domain over the tunnel. This causes broadcasts, ARP, unknown unicast packets and other Layer 2 effects to run over a WAN or Internet connection. This can worsen performance and make errors more difficult to understand. If the RED tunnel is unstable, this will also directly affect the stretched network.

In most cases, a routed design is better: Each location has its own subnets, the firewall routes between the networks and firewall rules specifically define what is allowed. This is cleaner, more scalable and much more convenient when troubleshooting.

LAG: Plan redundancy and bandwidth correctly

A Link Aggregation Group (LAG) combines several physical ports into a logical interface. This makes sense if you need redundancy to the core switch or want to provide more bandwidth between the firewall and switch. But LAG does not replace clean zoning. In the end, the LAG interface is still just an interface on which you can, for example, operate VLANs or assign a zone.

Sophos Firewall LAG interface with VLAN interfaces and physical LAG member ports
A LAG can serve as a common uplink. Several VLAN interfaces can be operated on it, while the physical ports are integrated as LAG members.

Sophos Firewall mainly supports two typical operating modes:

  • Active-Backup: One link is active, another takes over if it fails. This is simple and good for redundancy.
  • LACP (802.3ad): Multiple links can be used in parallel. This requires LACP on both sides, i.e. on the firewall and switch.

It is important: LACP only works properly if 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 you only create a LAG on the firewall but do not configure the switch appropriately, packet losses that are difficult to understand or asymmetrical connection problems often arise.

Some practical limitations apply to LAGs:

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

For small environments, a single clean trunk port is often sufficient. LAG is particularly worthwhile if the core switch is to be connected redundantly, if many VLANs run over the same uplink or if the firewall really needs more throughput to the switch.

XFRM: Understanding route-based IPsec as an interfaceA XFRM interface belongs to the topic 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. The Sophos Firewall creates an XFRM interface automatically when both the local and remote subnets are set to Any on an IPsec connection.

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

  • The XFRM interface is in the VPN zone.
  • Under Administration > Device access, IPsec must be allowed for the WAN zone so that the connection can be established.
  • If local or remote subnets are not Any, no XFRM interface is created.
  • MTU and MSS are particularly important for route-based VPN because IPsec creates additional overhead. The practical test procedure is in Sophos Firewall Check MTU and MSS for VPN problems.
  • An XFRM interface is not deactivated directly under Network > Interfaces, but rather via the associated IPsec connection under Site-to-site VPN > IPsec.

XFRM is particularly relevant for admins when SD-WAN routing, dynamic routing or multiple networks need to be properly controlled via a location tunnel. If all you need is a very simple site-to-site connection with two fixed networks, a classic policy-based tunnel is often easier to understand.

RED: External locations as a separate interface conceptRED interfaces are not a normal switch port. RED stands for Remote Ethernet Device and is used to connect an external location to the Sophos Firewall via an encrypted tunnel. This can be implemented with dedicated SD-RED hardware or with firewall-to-firewall RED connections.

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

  • Standard/Unified: The firewall manages the remote network. Traffic runs through the central firewall. Very easy to control, but dependent on the tunnel.
  • Standard/Split: Only defined target networks run through the tunnel, Internet traffic goes out locally at the location. Less bandwidth across headquarters, but less central control.
  • Transparent/Split: RED hangs transparently in an existing network. Good for special cases, but harder to understand and not suitable for every design.
  • Manual/Split: More manual network configuration. The site can continue to operate locally if the tunnel fails.

For many companies, Standard/Unified is the cleanest option if the location needs to be completely protected via the central firewall. The disadvantage is clear: If the RED tunnel fails, the location also loses centrally controlled Internet access, depending on the design. Standard/Split reduces this dependency, but also means that local Internet traffic is no longer completely filtered and logged via the central Sophos Firewall.

With RED you should check these points early:

  • The RED service must be activated at System services > RED.
  • TCP 3400, UDP 3410 and NTP 123 are typically required for the connection.
  • SD-RED devices need correct time, otherwise TLS handshake and tunnel establishment may fail.
  • When commissioning for the first time, DHCP on the uplink is usually easier because the device has to achieve 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, you should choose the operating mode particularly carefully.
  • If a RED device is behind a provider router, outbound connections and DNS/NTP must work.

RED is very convenient for small sites, but you shouldn’t treat it like a normal LAN cable. The decisive factor is whether the location should be centrally protected, locally autonomous or only partially connected via the tunnel. This decision affects DHCP, DNS, VLANs, routing, firewall rules, logging and troubleshooting.

Device Access cleanly restrictUnder Administration > Device access you can see which local firewall services are accessible from which zones. These include, among others:

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

For productive environments, the fewer local services that can be reached from a zone, the better. In particular, HTTPS and SSH should only be allowed from trustworthy management networks or via a Local service ACL exception rule.

If SSH is needed, this guide will help: Establish an SSH connection to the Sophos Firewall.

For custom zones, Device Access can also be visible directly when creating or editing the zone. Technically, this is still about local firewall services, not normal transit traffic. If clients use the firewall as a DNS server, DNS must be allowed for this zone. If admins need WebAdmin access, that should not be enabled broadly for the whole client zone, but through a management network or a Local Service ACL exception.

Keep dependencies in mind

Changes to interfaces are rarely isolated. Zone binding, DNS, gateways, SD-WAN routes, interface-based hosts, VLAN interfaces, Dynamic DNS, firewall rules and NAT rules can depend on the same interface. Before making major changes, check under Object usage where an interface, a zone or a host object is already in use. Sophos Firewall shows object usage and links directly to many dependent configurations.

You need to be particularly careful when deactivating or deleting:

  • If an interface is deactivated, the configuration is retained and the status is still visible.
  • Site-to-site IPsec tunnels where the firewall is the initiator are immediately disconnected.
  • Site-to-site IPsec tunnels as responders and remote access connections are disconnected at the latest due to inactivity or dead peer detection.
  • Alias ​​and XFRM interfaces cannot be deactivated directly like normal interfaces. Alias ​​interfaces follow the physical interface, XFRM interfaces are deactivated via Site-to-site VPN > IPsec.
  • When a virtual interface is deleted, dependent firewall rules, DHCP configurations, ARP entries, routes, interface hosts and other references can be removed with it.

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

Implement changes securely

Interface changes should be gradual. Remote locations, HA clusters, WAN interfaces, VLAN trunks, XFRM interfaces and management networks are particularly critical. A small change to the zone binding can be enough for firewall rules, Device Access or SD-WAN routes to no longer work as expected.

Proven process:

  1. Document current interface and zone configuration.
  2. Check dependencies via Object usage and note the most important hits directly.
  3. Create backup.
  4. Define maintenance window or fallback time.
  5. Add a new zone or new interface first, do not immediately delete the old configuration.
  6. Prepare test client or test traffic.
  7. After changing, check link status, IP address, gateway, DHCP and DNS.
  8. Validate firewall rule, NAT rule and Device Access with Log Viewer or Packet Capture.
  9. Only remove old rules, interfaces or objects once the new path is stable.

A backup is only part of the way back. Before critical interface or zone changes, it should also be documented which old IP address, zone, VLAN ID, gateway, route, SD-WAN route, firewall rule and NAT rule must be restored in the event of an abort. Sophos Firewall Create or restore backup is suitable for the actual backup and restore process.

  • Management zone or Device Access is adjusted: Alternative admin access is tested before the old accessibility is removed.
  • WAN interface or gateway is changed: Old provider path, PPPoE/DHCP/static values ​​and SD-WAN route are documented.
  • VLAN trunk is being converted: Old VLAN ID, native VLAN, switch port profile and firewall interface are traceable.
  • Bridge, LAG or RED is changed: Link status, involved ports and location access can be independently checked.
  • XFRM or VPN interface is changed: Tunnel, routing and firewall rules are validated before deleting the old path.

Particular attention should be paid to tagged/untagged behavior during VLAN migrations. If the switch and firewall use different VLAN IDs, native VLANs or trunk profiles, the firewall either sees no traffic at all or traffic ends up in the wrong zone.

For remote locations, there should always be an access path outside of the interface you just changed. This can be Sophos Central, a second WAN access, a local admin on site or a separate management network.

Typical stumbling blocks

Interface is unbound or disabled: First 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 not working: Check VLAN ID, Switch Port, Tagged/Untagged Configuration, Native VLAN and Parent Interface.

Clients cannot reach the firewall via ping or HTTPS: Do not check normal firewall rules first. Administration > Device access and local ACL exceptions are crucial.

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

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

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

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

MTU problems with VPN or PPPoE: Check MTU and MSS. For VPN traffic, an MTU value that is too high can lead to packet loss, which in everyday life looks like random connection problems. Sophos Firewall Check MTU and MSS for VPN problems is suitable for systematic limitation.

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 the original and translated carefully.
  6. Log viewer: Check which rule or drop applies.
  7. Diagnostics > Tools > Packet capture: Check whether packets arrive at all and where they are forwarded.

If zones and interfaces are properly laid out, the next step becomes much easier: Understand and correctly configure Sophos Firewall rules. If traffic does not work despite the apparently correct zone, the checklist Firewall rule doesn’t work: check order, matching and logs will help. For a deeper analysis you can also use Use Packet Capture in WebAdmin and for translations or port forwarding the article Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Operational checklist

  • Zone model documented: Client, server, management, guest, DMZ, WAN and VPN deliberately separated or deliberately combined.
  • New VLANs documented with VLAN ID, parent interface, switch port profile and gateway IP.
  • Zone and concrete IP host object documented for every important network.
  • Device Access checked per zone, especially for HTTPS, SSH, DNS, Ping, User Portal and VPN Portal.
  • Firewall rules created with source zone, destination zone, services and logging.
  • Alias checked instead of an additional WAN interface when several public IPs are used in the same provider subnet.
  • NAT rules checked if Internet access, DNAT, SNAT or VPN is involved.
  • DHCP, DNS and NTP tested for new networks.
  • Object usage checked before changes to existing interfaces.
  • Link status, Log Viewer and Packet Capture checked for changes.
  • Management access ensured via an independent path.
  • Backup available before major changes.

FAQ

Does each VLAN on Sophos Firewall need its own zone?

No. Multiple VLANs can be in the same zone if they are given the same trust level, firewall rules and Device Access. If a VLAN requires different rights, risks or management access, a separate zone is often clearer.

Why doesn't traffic between two LAN interfaces work automatically?

A zone is not an automatic permission. Appropriate firewall rules with correct source zone, destination zone, network objects and services are also required between internal interfaces.

What is most commonly wrong with VLANs on Sophos Firewall?

Typical causes are incorrect VLAN ID, incorrect parent interface, an untagged switch uplink, an incorrect native VLAN, missing DHCP server or a missing firewall rule.

When should you use Bridge instead of VLAN?

A bridge is particularly useful for simple setups, migrations or transparent designs. For new segmented networks, VLANs with clear zones and firewall rules are usually easier to maintain.

What should you check before deleting an interface?

Before deleting, Object usage should be checked. Firewall rules, NAT rules, DHCP, routing, SD-WAN, dynamic DNS, interface hosts, VPNs and Device Access are important. Deleting can remove dependent configurations or break connections.