Sophos Firewall VLAN set up and test

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

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 VLAN fits Sophos Firewall and configure UniFi switch. For special bridge cases according to 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 under 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 appropriate log entries is the VLAN cleanly accepted.

When a VLAN makes sense

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

Typical applications:

• Separate client network and server network
• Isolate guest WLAN from internal LAN
• Place VoIP phones in their own network
• Limit IoT, cameras or printers
• Management network for admin PCs, switches and monitoring create
• DMZ or lead server network via a common switch uplink

However, an VLAN does not replace firewall rules. It ensures technical separation on Layer 2. Whether traffic is allowed between VLANs is then decided by the Sophos Firewall via zones, routing, firewall rules, NAT and security policies.

VLAN planning architecture

The most important question is not how to create a VLAN. The more important question is what security areas should there be 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 disconnected.

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

This is not a rigid scheme. A small office doesn’t necessarily need ten VLANs. However, an environment with multiple locations, servers, WLANs, cameras, backup systems and external access should not put everything in one big 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 for finer segmentation:

• Place 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.
• Management-VLAN only open for admin devices and monitoring.

It is important: 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.

For ZTNA it is particularly helpful:

• 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 flat rate LAN to LAN or Any to Any rules will be dismantled.

If Sophos ZTNA is used later, you can get started via Plan and create Sophos ZTNA gateway. VLAN planning is not a necessary requirement for this, but it does make later operations 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.

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.

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.

Understanding 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:

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?

You can theoretically use your own physical firewall port per VLAN. This is understandable for very small installations, but scales poorly. Ports become scarce, the 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 a LAG transports multiple VLANs tagged.
3. On the firewall, separate VLAN interfaces are created on this parent interface for each VLAN.
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.

For many SME and medium-sized networks, Firewall as the default gateway for the VLANs is the better security decision. Then internal traffic between VLANs runs via 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 switch and firewall.
• The VLAN was created on the wrong parent interface.
• The parent interface was operated as a normal access port instead of as a trunk.

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. Network zone consciously select.
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.

DHCP and DNS set up

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

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 DHCP Configure Options.

When designing the DNS, you should clearly decide whether clients use the Sophos Firewall as DNS forwarders or directly ask internal DNS servers. 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.

Device Access check

Device Access controls local services of the 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.

firewall rules and NAT supplement

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:

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 Sophos Firewall-Understanding and Configuring Rules Safely.

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

Acceptance test

A VLAN is only ready when the packet flow is proven. A single ping is not enough.

Useful test sequence:

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 VLAN if ping is allowed.
5. DNS Test resolution for internal and external names.
6. Test permitted Internet access.
7. Test permitted internal access, if provided.
8. Deliberately test disallowed internal access and check block in Log Viewer.
9. In Log Viewer Check Rule ID, Source zone, Destination zone and NAT ID.
10. If unclear, use Packet capture on the VLAN interface.

For the evaluation with Log Viewer, Policy Test and Packet Capture, Sophos Firewall Test Rule with Log Viewer, Policy Test and Packet Capture is suitable.

Typical errors

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 the 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 what rules belong to it.

You should document:

• VLAN ID, name and subnet
• Parent interface and switch uplink
• Zone and security purpose
• DHCP source and DNS server
• allowed 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 ones deliberately remain separated.

A simple access matrix can look like this:

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