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.

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-new in DHCP, troubleshooting becomes unnecessarily tedious.

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 can also be planned on suitable RED interfaces if the site mode and switch side fit.
• 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. Assign Name, for example Clients VLAN 100.
2. Select the parent interface as Interface, for example Port3 or LAG1.
3. Choose Network zone consciously.
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.

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.

DHCP on the Sophos Firewall is created under Network > DHCP. Interface, range, gateway, DNS server and search domain are important. Special options such as PXE, VoIP or manufacturer-specific values ​​are described in Sophos Firewall Configure DHCP Options.

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.

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.

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.

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 admin logs.
• 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