Set up and test VLANs on Sophos Firewall

A VLAN on the Sophos Firewall is more than a VLAN ID. For the new network to really work, the parent interface, switch tagging, zone, IP address, DHCP, DNS, Device Access, firewall rules and NAT must all fit together.

The article describes the generic Sophos Firewall flow and key operational decisions around segmentation, zone, DHCP, rules and testing. When it comes to a concrete implementation with UniFi switches, the article Configure VLAN on Sophos Firewall and UniFi Switch is suitable. For special bridge cases after SFOS 22, Sophos Firewall Check bridge VLANs according to SFOS 22 is the better start.

Short answer

A VLAN is created on the Sophos Firewall at Network > Interfaces > Add interface > Add VLAN. After that you usually need:

• a suitable zone
• a static IP address as a gateway
• DHCP server or DHCP relay
• DNS design
• Device Access for local firewall services
• Firewall rules for the Internet, internal networks or servers
• Logging and a short acceptance test

Only when a test client shows the IP address, gateway, DNS, permitted connections, blocked connections and matching log entries is the VLAN cleanly accepted.

When a VLAN makes sense

VLANs logically separate Layer 2 networks from one another. On the Sophos Firewall they are often used to route multiple networks over the same physical uplink or LAG.

Typical applications:

• Separate client network and server network
• Isolate guest WiFi from internal LAN
• Place VoIP telephones in their own network
• Limit IoT, cameras or printers
• Create management network for admin PCs, switches and monitoring
• Run DMZ or server network over a common switch uplink

However, a VLAN does not replace firewall rules. It ensures technical separation on Layer 2. The Sophos Firewall then decides whether traffic between VLANs is permitted via zones, routing, firewall rules, NAT and security policies.

A VLAN can span multiple switches. Traffic between devices in the same VLAN is forwarded through the switches within that Layer 2 network and normally does not pass through the VLAN gateway. Even when Sophos Firewall is the default gateway, it therefore does not automatically inspect communication within the same VLAN. Traffic between different VLANs needs a Layer 3 path through a router, Layer 3 switch or firewall.

Plan VLAN architecture

The most important question is not how to create a VLAN. The more important question is what security areas should exist in the network. Many problems arise because VLANs are created purely technically: VLAN 10, VLAN 20, VLAN 30. After a few months, no one knows what communication should be allowed and why certain networks were separated.

We recommend planning VLANs first based on risk, function and operational responsibility. A good starting structure often looks like this:

• Management: Admin PCs, switches, Access Points, monitoring and controllers. Access to administrative interfaces should be very tightly controlled.
• Clients: Workstation devices, notebooks and normal user devices. This is usually the standard network with Internet access and targeted internal approvals.
• Server: Domain controller, file server and application server. Servers should not be directly accessible from every client network.
• Guests: Guest WiFi and external devices. This network normally only needs internet and no access to internal systems.
• IoT and cameras: Cameras, printers, sensors and building technology. Many of these devices have weak update and security models.
• VoIP: Telephones, PBX and SBC. Own DHCP options, QoS and clear accessibility are often helpful here.
• Backup: Backup servers, repositories and immutable storage. Separation protects against ransomware and lateral movement.
• DMZ: Publicly accessible systems or reverse proxies. Exposed services belong in a separate area.

This is not a rigid scheme. A small office does not necessarily need ten VLANs. However, an environment with multiple locations, servers, WLANs, cameras, backup systems and external access should not put everything in one large LAN.

Classify micro-segmentation realistically

Micro-segmentation does not mean that every single device needs its own VLAN. In practice, the better start is usually clean macro segmentation: clients, servers, management, guests, IoT, backup and DMZ are separated. Particularly critical systems can then be segmented more finely.

Examples of finer segmentation:

• Put the domain controller in its own server subnet.
• Make backup systems only accessible from a few sources.
• Allow camera network only to NVR or VMS.
• Make printers only accessible via print servers or defined client networks.
• Open management VLAN only for admin devices and monitoring.

What is important is that every additional separation also generates operating costs. It needs rules, logs, tests, documentation and someone to maintain the exceptions. Good segmentation is not as complicated as possible, but rather comprehensible and verifiable.

Preparation for ZTNA and modern access

A clean VLAN structure also helps later with ZTNA, VPN, SASE or other access concepts. If internal applications are already located in clear server or application networks, access can be published more specifically and you don’t have to release a complete flat LAN.

The following is particularly helpful for ZTNA:

• Application servers are in known server networks.
• Management access is separated from normal client traffic.
• DNS names and internal routes are clearly documented.
• Firewall rules show which user or location groups require which targets.
• Old blanket LAN to LAN or Any to Any rules will be dismantled.

If Sophos ZTNA is used later, you can access it via Plan and create Sophos ZTNA Gateway. VLAN planning is not a mandatory requirement for this, but it makes later operation much cleaner.

How many VLANs do you need?

There is no fixed correct number. You should create VLANs where your own security decision is necessary.

Having your own VLAN usually makes sense if at least one of these points applies:

• The network needs different firewall rules. Then you should plan your own zone or at least your own VLAN object.
• Device Access should look different. A separate zone is often cleaner.
• DHCP options differ, for example for VoIP, PXE or guest networks.
• Traffic should be logged, monitored or evaluated separately.
• The devices have a significantly different risk, for example IoT, guests, backup or management.
• There are other responsible parties or their own operating process.

But you shouldn’t immediately force every small special topic into a new VLAN. If two client networks get exactly the same rules, the same web policy and the same Device Access, a common zone with clear network objects may be sufficient.

Plan in advance

Before creating, the VLAN should be briefly documented. This doesn’t have to be a big network plan, but the most important values ​​should be clear.

A compact planning set is often enough:

• VLAN Name: for example Clients
• VLAN ID: for example 100
• Subnet: for example 10.100.0.0/24
• Gateway on Sophos Firewall: for example 10.100.0.1
• Parent Interface: for example Port3 or LAG1
• Zone: for example Client, LAN, Guest, Server or DMZ
• DHCP: Sophos Firewall, DHCP relay or external server
• DNS: Firewall, internal DNS servers or intentionally different design
• Purpose: for example workstation clients with Internet access

The zone is particularly important. This setting later affects firewall rules, Device Access, web policies, IPS, logs and troubleshooting. Sophos Firewall Configure zones and interfaces is suitable for basic zone planning.

The VLAN ID must be in the valid range 1 to 4094. The same VLAN ID cannot be added more than once on the same physical parent interface. In production networks, the ID should not only be assigned technically, but named consistently with switch configuration, Wi-Fi SSID, DHCP scope, documentation and monitoring. If VLAN 100 is called Clients on the firewall, Office on the switch and LAN-neu in DHCP, troubleshooting becomes unnecessarily tedious.

Sophos does not specify a fixed limit on the number of VLAN interfaces per physical interface on an XGS Appliance. That does not make an unlimited trunk a sound design. Sophos recommends spreading VLANs across multiple interfaces for better performance and manageability. Base the design on traffic load, the appliance model, required redundancy and whether an administrator can still understand the path during an outage.

Understand parent interface and switch tagging

The Parent Interface is the physical port, bridge or LAG on which the Sophos Firewall receives the tagged VLAN packets. The VLAN ID on the Sophos Firewall must match exactly what the switch is sending on this link.

Typical designs:

• Physical port as trunk: A switch uplink transports multiple VLANs tagged to the firewall.
• LAG as a trunk: Several physical ports form a LAG, on which there are several VLAN interfaces.
• RED interface: VLANs through an SD-RED 60 require Standard/Unified and matching LAN port modes. Choose the right Sophos RED operation mode explains the limits.
• Access port without VLAN tag: An end device hangs untagged in a VLAN. Tagging happens on the switch, not on the client.
• Bridge with VLANs: Special case that should be checked carefully, especially for migrations or transparent designs.

If a normal client PC is directly connected to a switch port, it normally sends untagged. The switch then assigns this port to a VLAN. The Sophos Firewall only sees the VLAN on the uplink when the switch transports the VLAN tagged to the firewall.

Individual ports or VLAN trunk via LAG?

Theoretically, you can use your own physical firewall port per VLAN. This is understandable for very small installations, but scales poorly. Ports become scarce, cabling becomes confusing and changes to zones, switches or HA become more tedious later.

In productive environments, a trunk design is usually cleaner:

1. The Sophos Firewall is connected to one or more core switches.
2. A physical port or LAG transports multiple VLANs tagged.
3. On the firewall, separate VLAN interfaces are created for each VLAN on this parent interface.
4. The firewall remains the default gateway for the VLANs and decides on routing and security policies.

Our preferred variant is often a LAG with two fast uplinks, for example 2x SFP+, as long as the firewall and switches support this. The VLANs then run on it as tagged interfaces. This doesn’t automatically mean twice the speed for a single session, but it does provide more redundancy, more reserves and a clearer design than many individual copper ports per VLAN.

The most important variants:

• One firewall port per VLAN: ​​easy to understand and can be implemented with little VLAN knowledge. But it scales poorly, requires a lot of ports and quickly makes the cabling confusing.
• One trunk port with VLANs: simple, clean and with few cables. However, the individual uplink remains a single point of failure.
• LAG with VLAN trunk: redundant, clean and easily scalable. The switch and firewall must correctly support LAG or LACP.
• Routing on core switch: very performant in large networks. However, the firewall no longer completely sees internal east-west traffic.

For many SME and medium-sized networks, firewall as the default gateway for the VLANs is the better security decision. Internal traffic between VLANs then runs over the Sophos Firewall and can be controlled with firewall rules, IPS, web policies, logging and later security functions. Routing on the core switch can be useful if very high internal east-west throughput is required. But then you have to consciously accept that the firewall no longer sees every internal communication.

As a rule of thumb:

• Security-oriented and clear: VLAN gateways on the Sophos Firewall.
• Very high internal performance: Check routing on core switch, but add security zones and ACLs cleanly.
• New installations: Route VLANs to the firewall via trunk or LAG, do not waste a single port per VLAN.
• Small sites: A single trunk port may be sufficient if redundancy is not required.

Common misconceptions:

• The VLAN is created on the firewall, but the switch uplink does not transport it.
• The VLAN is tagged on the access port, although the client expects it to be untagged.
• The VLAN ID does not match on the switch and firewall.
• The VLAN was created on the wrong parent interface.
• The parent interface was operated as a normal access port instead of a trunk.
• A VLAN was already created on the parent interface, and the physical port is then supposed to be changed spontaneously to DHCP or PPPoE. Such changes must be planned beforehand because Sophos does not allow the IP assignment of a static physical interface to be changed freely to DHCP or PPPoE after VLAN configuration.

Create VLAN interface

Menu path:

Network > Interfaces > Add interface > Add VLAN

Procedure:

1. Enter a Name of no more than 58 characters, for example Clients VLAN 100. You can change it later, and SFOS displays it in other settings.
2. Select the parent interface as Interface, for example Port3 or LAG1.
3. Choose Zone deliberately.
4. Enter VLAN ID, for example 100.
5. Under IPv4 configuration usually use Static.
6. Enter the IP address and subnet mask, for example 10.100.0.1/24.
7. Save.

For internal VLANs, the firewall IP is usually the default gateway of the clients. If another system is routing or the firewall only sees certain networks, this design must be explicitly documented. Otherwise you’ll search for firewall rules later, even though the client isn’t using the Sophos Firewall as a gateway.

After saving, expand the parent interface under Network > Interfaces or use the VLAN filter. Sophos shows VLAN interfaces below the parent interface and also in the VLAN view. The automatically generated hardware name is based on parent interface and VLAN ID. For operations, the descriptive interface name is more important because it appears in other settings, logs and rules.

To change an existing VLAN, go to Network > Interfaces > VLAN, open that VLAN’s menu and select Edit interface. Save the changes with Save, then recheck the affected connections. Before changing the gateway, zone or parent interface, make sure an independent administrative access path is available.

IPv4 assignment for internal and WAN VLANs

Static is almost always the right choice for an internal VLAN because clients need a stable default gateway. If you select the WAN zone, SFOS also asks for a Gateway name and, with static assignment, a Gateway IP address.

A WAN VLAN can use DHCP or PPPoE under IPv4 configuration instead. With DHCP, SFOS shows the address, netmask and gateway IP supplied by the provider. PPPoE requires at least a Username and Password. Preferred IP is only a request, and the PPPoE server may assign another address. Set Access concentrator/service name only when the provider requires a specific service.

Change LCP echo interval or LCP failure only when measurements or provider requirements justify it. Clearing either checkbox does not disable LCP. It restores the defaults of 20 seconds and 3 unanswered requests. Put Schedule time for reconnect in a maintenance window because the provider may assign a dynamic address rather than the preferred address after reconnection. Recheck gateway status, public address, DNS, NAT and a real internet connection afterwards.

With PPPoE, IPv4/netmask displays the IPv4 address and subnet mask assigned by the provider; Gateway IP address displays the configured gateway’s IP address. These are displays, not static input fields. Access concentrator/service name restricts connection attempts to access concentrators that can provide the specified service. LCP echo interval sets the interval between echo requests used to check the link. If the requests specified by LCP failure remain unanswered, SFOS disconnects the PPPoE connection. For unexpected disconnects, check the link and provider first rather than simply increasing the threshold.

IPv6, prefix delegation, and router advertisements

Under IPv6 configuration, choose from Static, DHCP, and Delegated. A WAN VLAN can obtain its IPv6 address through DHCPv6. In Auto mode, SFOS selects the method, while Manual distinguishes between DHCP only and Stateless. With Stateless, address configuration follows the M and O flags in the received router advertisements; Accept other configuration from DHCP can obtain additional values such as DNS through DHCPv6.

For Static under IPv6 configuration, enter the planned IPv6 address and prefix in IPv6/prefix. When Zone is set to WAN, also enter Gateway name and the gateway’s IPv6 address in Gateway IP address. The address, prefix and gateway must match your provider or network plan.

To distribute a provider prefix, turn on DHCP prefix delegation on the WAN VLAN. Preferred delegated prefix accepts prefix lengths /48, /52, /56, or /60; the provider may still delegate a different prefix. DHCP rapid commit shortens the exchange only when the DHCPv6 server also supports Rapid Commit.

The prefix address in Preferred delegated prefix is optional: you can leave it blank while specifying one of the supported prefix lengths. Server support is not enough for DHCP rapid commit; Rapid Commit must also be enabled on the DHCPv6 server. With IPv6 assignment set to DHCP, the WAN zone also requires Gateway name; Gateway IP displays the configured gateway’s IPv6 address.

The internal VLAN then uses Delegated and the prepared WAN interface as its Upstream interface. SFOS derives the VLAN’s IPv6 address and subnet from it. Router advertisement supplies addressing information to clients; the optional DHCPv6 server supplies additional parameters such as DNS, but no IPv6 addresses in this mode. Configure IPv6 prefix delegation on Sophos Firewall explains the complete provider and subnet workflow, while IPv6 router advertisements on Sophos Firewall covers the client side.

In Delegated mode, IPv6 address displays the assigned address, including the delegated prefix, subnet ID, interface ID and prefix length. Use this composition to check that the VLAN has the expected prefix and subnet. If this interface is assigned to the WAN zone, also enter Gateway name and the IPv6 gateway address in Gateway IP; the usual internal VLAN does not use that WAN input branch.

For a VLAN using DHCPv6, DAD attempts limits the Duplicate Address Detection attempts. Under Allowed RA servers, allow only the expected router-advertisement sources by their MAC or IPv6 address. Both settings belong to the documented IPv6 topology and should not be changed speculatively or opened broadly.

Here, DAD attempts counts the consecutive Neighbor Solicitation messages sent to perform Duplicate Address Detection on a tentative address, not connection attempts to the provider.

For firewall rules, also create a matching network object:

Hosts and services > IP host

Example:

• Name: NET_Client_VLAN100
• IP version: IPv4
• Type: Network
• IP address: 10.100.0.0
• Subnet: /24

Such objects make rules, log searches and later reviews much clearer than raw IP ranges in every individual rule.

Set up DHCP and DNS

After the VLAN interface, a decision is needed to assign addresses.

• DHCP on Sophos Firewall: suitable for simple sites, client, guest, IoT or VoIP networks.
• DHCP Relay: useful for a central Windows DHCP server or existing DHCP infrastructure.
• External DHCP server in the VLAN: ​​Special case when a server is responsible directly in the VLAN.
• Static IPs: suitable for small server, management or infrastructure networks.

Configure Sophos Firewall as a DHCP server explains how to plan and test the address range, gateway, DNS, lease time and static assignments. Special options such as PXE, VoIP or manufacturer-specific values are described in Configure DHCP options on Sophos Firewall.

Sophos Firewall can configure DHCP server and DHCP relay on physical and virtual interfaces such as VLANs, wireless networks and bridges. Alias interfaces are not the right place for this. If DHCP is planned across VPN paths, also check whether the specific VPN design supports DHCP relay; with route-based VPNs, this is not automatic.

When designing DNS, you should clearly decide whether clients use the Sophos Firewall as DNS forwarders or ask internal DNS servers directly. When the firewall acts as a DNS forwarder, internal domains often need to be forwarded to the correct DNS servers via DNS Request Routes on Sophos Firewall.

Check Device Access

Device Access controls local services of Sophos Firewall. This is not the same as a firewall rule between VLANs.

Typical examples:

• Clients should use the firewall as a DNS server: allow DNS for the zone.
• Troubleshooting should allow ping on the firewall: consciously enable Ping/Ping6.
• Normal client, guest or IoT VLANs should not have WebAdmin or SSH access.
• Management access should be via a dedicated admin network or Local Service ACL Exception Rules.

The exact procedure is in Sophos Firewall Secure access: Configure Device Access correctly.

Add firewall rules and NAT

A new VLAN then needs appropriate firewall rules. Without a rule, a client can get an IP address, but not automatically on the Internet or other internal networks.

Create a new rule under Rules and policies > Add firewall rule > New firewall rule. Enter the source and destination zones, network objects and services from your VLAN plan, then save it with Save.

VLAN-specific firewall rules can also require user authentication. Access then depends not only on the source network and zone, but also on the signed-in user or their group. A VLAN alone does not authenticate users; configure the appropriate authentication and check it with both an authorised and an unauthorised test user.

A simple first internet rule could look like this:

• Rule name: Clients_to_WAN
• Source zones: Client or LAN
• Source networks: VLAN network, for example 10.100.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: consciously required services, not automatically Any
• Log firewall traffic: activated

Separate rules should be created for internal access. A guest, IoT or camera VLAN should not be allowed into the server or management network across the board. Rule planning is described in more detail in Understand and safely configure Sophos Firewall rules.

The official inter-VLAN example places both VLAN networks in the source and destination of one LAN-to-LAN rule. That works as a lab example, but it is usually too broad for production segmentation. Prefer directional rules such as Clients_to_Server_HTTPS, from NET_Client_VLAN100 to one server object and only HTTPS. Add a reverse rule only if systems in the server network must initiate connections to clients. The log then shows which direction was intentional.

NAT is not necessary for all VLAN traffic. For normal Internet access, the existing MASQ or SNAT rule is often used. NAT is usually wrong between internal VLANs because target systems then no longer see the real client IP. The classification is in Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Acceptance test

A VLAN is not complete until packet flow is proven. A single ping is not enough.

Useful test procedure:

1. Attach the test client to the intended switch port or SSID.
2. Check whether the client receives an IP address from the correct VLAN.
3. Check gateway, DNS server and search domain.
4. Ping firewall IP in the VLAN if ping is allowed.
5. Test DNS resolution for internal and external names.
6. Test permitted internet access.
7. Test permitted internal access, if provided.
8. Test intentionally not allowed internal access and check block in Log Viewer.
9. In Log Viewer, check Rule ID, Source zone, Destination zone and NAT ID.
10. If anything is unclear, use Packet capture on the VLAN interface.

Sophos Firewall Test rule with Log Viewer, Policy Test and Packet Capture is suitable for evaluation with Log Viewer, Policy Test and Packet Capture.

Typical errors

• VLAN not allowed on the switch uplink: The client does not get an IP address or does not reach the gateway. Check trunk or tagged VLAN on the switch.
• Incorrect Parent Interface: The firewall does not see the traffic. Compare VLAN interface and physical cabling.
• VLAN ID already exists on the same parent interface: Sophos Firewall does not allow the same VLAN ID twice on the same physical interface. Check existing VLAN interfaces instead of creating a duplicate.
• Client port tagged instead of untagged: Normal clients do not end up in the VLAN. Check access port or native VLAN profile.
• DHCP missing or incorrect DHCP answers: The client does not receive an IP address or receives an incorrect IP address. Check DHCP leases and Packet Capture for UDP 67/68.
• No IP host object for the VLAN: Rules contain raw networks or wrong objects. Create the IP host cleanly under Hosts and services and use it in rules.
• DNS Device Access is missing: IP traffic works, but name resolution does not. Device Access and check client DNS.
• Wrong zone selected: Rules or policies do not apply as expected. Compare interface zone and firewall rules.
• Firewall rule missing: The client has an IP address, but traffic is blocked. Check Log Viewer and Rule ID.
• NAT between internal VLANs: Target systems see an incorrect source IP. Check NAT rules and plan internal NAT exceptions.

If a rule is not matched, the problem is often with zone, Source Network, gateway or switch tagging. The article Sophos Firewall Rule does not apply: Check causes helps with the distinction.

Roll back the change

Do not delete a VLAN interface as the first troubleshooting step. First restore the previous switch-port or SSID assignment and check which DHCP configuration, rules, NAT rules, routes and objects use the VLAN. This keeps the last working configuration available. Before deletion, verify an independent administrative path and remove every dependency or assign it to another interface.

To remove a VLAN after a controlled migration, go to Network > Interfaces > VLAN, open the interface menu and select Delete interface. Then confirm that the VLAN is no longer required on the switch trunk and that no clients receive addresses from its subnet. A failed rollout usually needs the smaller rollback: restore the previous port or SSID assignment, disable the new rules and leave the VLAN interface in place until you know the cause.

Operational check

For productive VLANs, not only the initial configuration should be correct. It is crucial that later admins can understand why the VLAN exists and which rules belong to it.

You should document:

• VLAN ID, name and subnet
• Parent interface and switch uplink
• automatically generated hardware name and descriptive interface name
• Zone and security purpose
• IP host object for firewall rules
• DHCP source and DNS server
• permitted target zones and services
• NAT decision
• responsible owner
• Test client or test procedure
• Date of the last rule check

For larger environments, a simple access matrix is also worthwhile. Such a matrix shows which VLANs are allowed to talk to each other and which are deliberately kept separate.

A simple access matrix can look like this:

• Clients to Internet: allowed with Web Policy, DNS Protection and logging.
• Clients to server: only defined application ports.
• Guests to internal: blocked.
• IoT to Internet: only required destinations and ports.
• IoT to Server: only to NVR, print server or management systems.
• Management to infrastructure: allowed for administrative protocols.
• Backup to server: specifically allowed, severely limiting reverse direction.

This matrix is ​​often more important than the VLAN list itself. This prevents general rules from being created later that actually nullify the segmentation.

Frequently Asked Questions