Sophos Firewall Check bridge VLANs for SFOS 22

Bridge interfaces on Sophos Firewall are practical if an existing Layer 2 network is to be continued transparently or a migration is to be implemented without immediate IP changes. However, with VLANs on a bridge, the design quickly becomes error-prone: There is then forwarding between networks, traffic to the firewall itself, Device Access, DNS, AD, authentication and often old CLI configurations.

Exactly at this point there is an important operating case with SFOS 22. Sophos lists an issue in the current Known Issues list where bridge interfaces with CLI VLAN tag configurations in SFOS 22.0 GA and SFOS 22.0 MR1 do not correctly process VLAN-tagged traffic if this traffic originates from the Sophos Firewall itself or ends on the firewall. For example, this can affect Active Directory, DNS, Device Access, STAS, LDAP, RADIUS or management access, even though normal traffic is routed through the bridge.

Sophos now also describes legacy CLI VLAN tagging as deprecated. Such legacy configurations can prevent upgrades to SFOS 22.0 MR2 and later versions. This check is therefore not only troubleshooting after an upgrade, but also useful preparation before the next maintenance window.

This article is not a general VLAN fundamentals chapter. For planning zones, interfaces, VLANs, bridges and LAGs, Sophos Firewall Configure zones and interfaces fits first. This is specifically about the bridge VLAN special case after SFOS 22.

When this topic is relevant

The check makes sense when several points come together:

The firewall runs on SFOS 22.0 GA or SFOS 22.0 MR1.
There is a bridge interface, for example br0.
VLANs were historically built using CLI VLAN tag configuration like system vlan-tag or were taken over from an old configuration.
Firewall services themselves must achieve a tagged VLAN.
After an upgrade, AD, DNS, authentication, monitoring or management access only partially work.
An upgrade to SFOS 22.0 MR2 or later is planned or is blocked because of legacy CLI VLAN tagging.
Normal client traffic through the bridge appears to still be running.

The last point is important: If the bridge continues to forward traffic between networks, the problem will not initially appear to be a bridge failure. In practice, it’s easy to look in the wrong place, such as firewall rules, DNS, STAS or the domain controller.

Understand affected traffic direction

You have to clearly separate three types of traffic.

The types of traffic differ significantly:

Traffic passed through the bridge: A client in VLAN 100 is talking to a server in VLAN 100. This may still work, but does not prove that traffic to the firewall is working.
Traffic to Firewall: A client uses the firewall as a DNS server or WebAdmin destination. It is precisely this traffic that can be affected because it ends at the firewall.
Traffic from the firewall: The firewall queries AD, DNS, LDAP, RADIUS, NTP or Syslog destinations. This is also critical because the firewall itself is the sender.

If only one application is tested between two hosts, the error cannot be identified with certainty. The test must deliberately include a service that ends on the Sophos Firewall or is created by the firewall.

Typical symptoms

Possible signs are:

User-based rules no longer work reliably because AD, STAS or LDAP cannot be reached in a stable manner.
DNS queries to the firewall fail from individual VLANs.
Ping or HTTPS on local firewall services does not work from a VLAN, even though the firewall rules look plausible.
Monitoring or Syslog appears incomplete if the firewall has to reach a target in a tagged VLAN.
Packet Capture shows that traffic between end systems is visible, but firewall services themselves are not responding as expected.
After a SFOS-22 upgrade, the symptoms occur without consciously changing anything on the switch or firewall rules.

Such symptoms should not be immediately addressed with broad allow rules or device access approvals. First, it must be clear whether the interface design itself is affected.

Quick demarcation before conversion

Before moving a bridge IP or creating new VLAN interfaces on the bridge, you should narrow down the cause. Not every problem after an upgrade is automatically the SFOS-22-Bridge-VLAN case.

Practical classification:

Just a single application between two hosts doesn’t work: More likely are firewall rule, NAT, target system or return path. First test firewall rule and for drops analyze dropped packets.
WebAdmin, DNS or ping to the firewall from a VLAN does not work: Check Device Access, zone, local service or bridge VLAN special case. Then test traffic to the firewall separately.
Firewall does not reach AD, LDAP, RADIUS, DNS or Syslog in VLAN: Check traffic from the firewall, routing, DNS or bridge VLAN special case. Use tests directly from the firewall configuration and appropriate service logs.
Normal client traffic is running, but services of the firewall itself are not: Bridge VLAN special case becomes more likely. Check bridge design, old CLI VLAN tag configuration and VLAN interface for bridge.
There are no matching log entries at all: Check logging, filter, local service or non-logged bridge/NAT special case. Combine Log Viewer, Packet Capture and relevant Sophos Firewall service logs.

For DNS problems, it is also important whether clients use the firewall as a resolver or whether the firewall itself uses DNS request routes to internal servers. The second case concerns traffic from the firewall and may appear different than normal client traffic for Bridge VLAN issues. The basics are in Setting up DNS request routes on Sophos Firewall.

If the quick demarcation clearly points to local firewall services or traffic generated by the firewall, the conversion should still be planned. A bridge correction without backup, maintenance window and alternative access path is too risky for productive networks.

Include existing design

Before making changes, you should document the current status. Particularly important are:

Name of the bridge interface, for example br0.
Bridge members, i.e. participating physical interfaces, VLANs, RED interfaces or LAGs.
IP address of the bridge, if available.
VLAN IDs that pass over the bridge.
Switch port profile: Tagged VLANs, Native VLAN, Trunk or access port.
Services ending on the firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
Services that the firewall must reach: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

If the structure comes from an old migration, you should also check whether VLANs were set up via CLI configuration. It is precisely this legacy that is often no longer in mind when the firewall has only been updated over the years.

⚠️ You should not spontaneously experiment with bridge interfaces and VLANs during day-to-day operations. An incorrect change can affect management access, DNS, authentication, or entire client networks. Before the correction, a backup, a maintenance window and an alternative access path are required.

Bridge-specific pitfalls before the correction

Sophos describes three bridge restrictions that should be checked consciously before the change.

First: A bridge without an IP address can drop traffic if the traffic matches a firewall rule with web proxy filtering or a NAT rule. According to Sophos, these drops aren’t logged. If a NAT rule is still required, it must be scoped so that source translation for the bridge interface without an IP address remains Original. Otherwise, you may search Log Viewer for a drop that never appears there.

Second: VLAN filtering on the bridge applies only to bridged traffic, not routed traffic. If Filter VLANs is enabled but no permitted VLAN IDs are entered, tagged traffic from all VLANs is dropped, while untagged traffic is excluded. During testing, this can look like an inconsistent VLAN issue.

Third: Bridge interfaces aren’t a replacement for every design. Sophos lists restrictions for Dynamic DNS, DHCP client, PPPoE and IPsec VPN. If one of these functions is part of the target design, the bridge workaround shouldn’t be applied in isolation; the interface design should be reassessed.

Workaround and Upgrade Preparation

A practical way is to create VLAN interfaces in Network > Interfaces using the bridge interface as the parent interface.

New or cleaned-up designs should no longer rely on system vlan-tag. If such CLI tags still exist, document them, migrate them to WebAdmin VLAN interfaces, and only then continue the firmware upgrade. This reduces both the SFOS 22 bridge special case and later upgrade blockers.

Examples:

VLAN 100: br0.100
VLAN 200: br0.200

When creating the VLAN in WebAdmin, three fields matter most: Interface must be the bridge, Zone must match the security purpose of the VLAN, and VLAN ID must be unique. Sophos allows WebAdmin VLAN IDs from 1 to 4094; the same VLAN ID shouldn’t be planned more than once on the same parent interface.

The process depends on whether the bridge itself already has an IP address.

If the bridge does not need an IP address

If the bridge is only supposed to forward transparently, it can be operated without its own IP address. The IP address for the affected VLAN is then on the VLAN interface, for example br0.100.

Practical process:

Create backup.
Document current bridge and VLAN configuration.
Add a new VLAN interface under Network > Interfaces.
Select the bridge as the parent interface, for example br0.
Enter VLAN ID.
Choose your zone consciously.
Set IP address on the VLAN interface if the firewall should be in this VLAN Gateway or local service.
Check Device Access for the zone.
Check firewall rules and NAT rules.
Validate with a test client.

The zone is not just order in the WebAdmin. This decision affects firewall rules, Device Access, logs and many later troubleshooting steps. If a VLAN is intended as a management, server or client network, this should be visible in the zone.

If the bridge previously had the production IP address

If the bridge is currently using the IP address that must be reachable in the VLAN in the future, you should be particularly careful. There are two clean variants for the conversion: the bridge receives a different IP address, or the bridge remains without an IP address. The previous production address is then assigned to the VLAN interface.

This is a change with risk of failure. It should be clarified beforehand:

Which address is used to reach WebAdmin?
Which clients use the firewall as default Gateway?
Which DNS or DHCP settings point to this address?
Which device access rules apply to the previous zone?
Is there a second management access from an unaffected network?

For remote locations, this change should not be planned without a local return path. If WebAdmin and SSH run over exactly the affected bridge IP, an error can interrupt administrative access.

Device Access and check firewall rules afterwards

After creating the VLAN interface, it is not enough to just test the IP address. Device Access and firewall rules must match the new interface and zone design.

To check:

Administration > Device access: Are Ping/Ping6, DNS, HTTPS, SSH, User Portal or VPN portal only allowed in the correct zones?
Rules and policies > Firewall rules: Are there rules for the new zone?
Rules and policies > NAT rules: Is traffic translated unexpectedly?
Network > DNS or DNS Request Routes: Is the firewall reaching the correct DNS or AD servers?
Authentication > Servers: Are AD, LDAP or RADIUS accessible after the change? For local firewall services, Device Access securely configure Sophos Firewall is the appropriate in-depth article. Sophos Firewall Test rule with Log Viewer and Packet Capture helps for rule analysis.

Validation after correction

A clean test should contain more than one ping.

Test from the affected VLAN

Check from a client in the affected VLAN:

Reach default Gateway.
Test the firewall IP on the new VLAN interface via ping, if allowed.
Test DNS against the firewall if the firewall serves as a DNS resolver.
Test WebAdmin or portal only from permitted management networks.
Check a typical application or server connection.
Check Log Viewer for matching rule ID and zone.

Test from the firewall

Separate tests are required for traffic that the firewall itself generates:

Test AD or LDAP servers in Authentication > Servers.
Check DNS resolution via firewall.
Check NTP, Syslog or monitoring target if these services are in VLAN.
Use Packet Capture on the VLAN interface when it is unclear whether packets are leaving the firewall.

If STAS or user-based rules are affected, Set up STAS on Sophos Firewall should also be checked. For SFOS-22 upgrades, this point also belongs in the SFOS 22 Upgrade Check.

Common errors

Typical pitfalls:

Test client-to-server traffic only: The bridge appears healthy, although local firewall services are affected. Also test traffic to and from the firewall.
Move bridge IP without plan: WebAdmin, DNS or Gateway may fail. Prepare backup, maintenance windows and alternative access.
Select zone incorrectly for the new VLAN interface: Rules, Device Access and logs do not fit. Choose a zone based on security purposes, not based on habit.
Device Access open too wide: The problem seems solved, but management services are unnecessarily accessible. Local Service ACL plan specifically.
Do not check switch port: VLAN arrives incorrect or untagged. Validate Tagged/Untagged, Native VLAN and Trunk profile.
Ignore old CLI configuration: Error remains unexplained after upgrade. Document old design and migrate to WebAdmin-VLAN interfaces.

Checklist

SFOS version and known issue relevance checked.
Bridge interface, bridge members and VLAN IDs documented.
Clarified whether old CLI VLAN tag configuration was used.
Bridge-specific NAT/web proxy drops and VLAN filtering checked.
Planned upgrade to SFOS 22.0 MR2 or later checked against legacy CLI VLAN tags.
Affected services to and from the firewall identified.
Backup and alternative management access available.
VLAN interface planned with bridge as parent interface.
Zone, Device Access, firewall rules and NAT rules checked.
Tests carried out from the VLAN and from the firewall.
Result recorded in the change log or in the network documentation.

FAQ

Why does normal traffic work through the bridge but DNS to the firewall doesn't?

In this SFOS-22 special case, passed-through VLAN traffic can continue to work, while VLAN tagged traffic ending on or originating from the firewall is affected. Therefore, you have to test local firewall services separately.

Should you generally avoid bridge VLANs on Sophos Firewall?

Not generally. Bridges can be useful for migrations or transparent designs. For new segmented networks, however, separate VLAN interfaces with clear zones are usually clearer and easier to operate.

Can the problem be solved with a firewall rule?

Not reliable. If the interface design is affected, an additional Allow rule will not change the cause. First you should check whether the VLAN has to be created correctly as an interface on the bridge.

What should you check before making changes to the bridge IP?

You should clarify whether WebAdmin, DNS, DHCP, default Gateway, authentication or monitoring use this address. In addition, a current backup and an alternative access path are required.