Replace legacy bridge VLAN tagging before SFOS 22 MR2

Bridge interfaces are useful when an existing Layer 2 network must remain transparent or during a migration without immediate IP changes. If VLAN tags were previously set on a bridge with system vlan-tag, replace that configuration with VLAN interfaces in WebAdmin before upgrading to SFOS 22.0 MR2 or later. This isn’t a cosmetic change: traffic to or from the firewall can fail on GA and MR1, and the legacy configuration blocks the upgrade from MR2 onward.

Issue NC-181672 affects bridge interfaces with CLI VLAN tag configurations on SFOS 22.0 GA and MR1: VLAN-tagged traffic originating from or destined to Sophos Firewall isn’t processed correctly. This can affect Active Directory, DNS, Device Access, STAS, LDAP, RADIUS, or management access even while the bridge continues to forward traffic between networks.

Legacy CLI VLAN tagging is deprecated. A firewall with this configuration on a bridge can’t upgrade to SFOS 22.0 MR2 or later. A backup containing it also can’t be restored to SFOS 22.0 GA or later. Perform this check before the upgrade and before creating the backup intended for it. The SFOS 22 upgrade check documents the verified target release MR2 Build 546, its upgrade path, and further version-specific blockers. If you plan a different target build, have the internal upgrade check updated before the change; don’t carry the MR2 details over without verification.

This article is not a general VLAN fundamentals chapter. For planning zones, interfaces, VLANs, bridges and LAGs, start with Configure zones and interfaces on Sophos Firewall. The normal setup, hardening and validation workflow is covered in Set up a bridge interface on Sophos Firewall. This article focuses specifically on 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

Three bridge restrictions must be checked carefully 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. 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. Restrictions apply to 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.

Create Supported VLAN Interfaces

The supported workaround is to create VLAN interfaces in Network > Interfaces and use the bridge as the parent. Physical, RED, bridge, and LAG interfaces are valid parents.

Before SFOS 18.0, system vlan-tag was required to enable VLAN-tagged communication over bridge interfaces. Since SFOS 18.0, VLAN-over-bridge has been fully available in WebAdmin. No Device Console or Advanced Shell path, menu number, prompt, or privilege level is specified for the following CLI command. Use only the supported CLI context on the firewall in which the command is available; if it isn’t available, stop and ask Sophos Support rather than guessing a shell or context. First use this read-only command to verify whether the legacy configuration is actually present:

system vlan-tag show

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. WebAdmin accepts 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:

1. Export a backup for documentation, but don’t rely on it as a restorable rollback on SFOS 22.
2. Document current bridge and VLAN configuration.
3. Go to Network > Interfaces and select Add interface > Add VLAN.
4. Select the bridge as the parent interface, for example br0.
5. Enter VLAN ID.
6. Choose your zone consciously.
7. Set IP address on the VLAN interface if the firewall should be in this VLAN Gateway or local service.
8. Check Device Access for the zone.
9. Check firewall rules and NAT rules.
10. Validate with a test client and create a new backup only after acceptance succeeds.

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.

Remove the legacy configuration and prepare the upgrade

Sequence matters: first create every required VLAN interface under Network > Interfaces with the bridge as its parent, move the existing bridge IP to the correct VLAN interface if necessary, and validate the new data and management paths. In an HA deployment, first confirm through the supported status interface that peer and synchronization status are healthy, and back up each node where the platform and support procedure require it. If the peer or synchronization status is unhealthy or unclear, stop before reset or upgrade and escalate. Don’t invent an HA or synchronization command.

Only after the mapping is documented, alternative access is active, and any HA preconditions are met should you remove the legacy setting in the same supported CLI context described above:

system vlan-tag reset

Run system vlan-tag show again. If legacy configuration remains, the reset fails, or the output is ambiguous, stop: don’t start the upgrade and don’t approve the new backup as a cleaned restore point. Save the command output, upgrade precheck, and current configuration, then escalate to Sophos Support rather than trying undocumented CLI commands.

There is no documented command-level reversal for system vlan-tag reset. Passing the post-reset inventory and traffic tests verifies cleanup, not rollback. After running reset, don’t attempt to recreate the legacy setting with a guessed command. If the change must be backed out, stop and escalate to Sophos Support for a vendor-approved restore on the original supported firmware; the documented WebAdmin changes may be reversed only as part of that approved plan.

After acceptance tests and the repeated inventory check succeed, create a new backup, rerun the upgrade precheck, and only then upgrade to SFOS 22.0 MR2 or later. Use the same cleanup path to produce a restorable future backup: remove the legacy setting on the source firewall, optionally create a VLAN interface with the bridge as its parent where needed, validate, and only then create a new backup. This does not repair an old backup containing system vlan-tag.

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:

1. Reach default Gateway.
2. Test the firewall IP on the new VLAN interface via ping, if allowed.
3. Test DNS against the firewall if the firewall serves as a DNS resolver.
4. Test WebAdmin or portal only from permitted management networks.
5. Check a typical application or server connection.
6. 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 Diagnostics > Packet capture on the VLAN interface when it is unclear whether packets leave the firewall. Generated identifies packets created by the firewall and Consumed packets destined for it; also compare In interface, Out interface, Rule ID, Status, and Reason.

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.

Rollback and Completion

Before the change, record the bridge IP address, zone, VLAN IDs, switch port configuration, and dependent rules and services. Prepare an alternative or local management path and a vendor-approved recovery plan. Before system vlan-tag reset, planned WebAdmin changes can be reversed in their documented order: if the IP address was moved, remove it from the new VLAN interface before assigning it back to the bridge, then restore the zone, rules, Device Access, and switch port profile and confirm management and gateway reachability. This is not a reversal of the reset command.

After system vlan-tag reset, there is no documented command-level reversal. If acceptance fails at that point, stop rather than recreating the legacy setting. Escalate for a vendor-approved restore on the original supported firmware. In HA, don’t reset or upgrade either node while peer or synchronization health is unhealthy or unclear, and retain the applicable backup for each node.

After successful acceptance, create a new backup. The old backup containing legacy CLI VLAN tagging isn’t a rollback path for SFOS 22.0 GA or later. If the legacy configuration remains after the WebAdmin migration or the upgrade precheck still reports it, save the configuration and message and contact Sophos Support rather than trying further undocumented CLI changes.

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 for each applicable node and alternative management access available; HA peer and synchronization status healthy.
• 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.
• Recovery boundary recorded: no documented reversal for system vlan-tag reset; new backup created after successful cleanup.
• Result recorded in the change log or in the network documentation.

FAQ