Check Sophos Firewall Bridge-VLANs after SFOS 22
Bridge interfaces on Sophos Firewall are practical when an existing Layer 2 network needs 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.
This is precisely where there is an important operational case with SFOS 22. Sophos lists a problem 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 when this traffic originates from or ends on the Sophos Firewall itself. This can affect, for example, Active Directory, DNS, Device Access, STAS, LDAP, RADIUS, or management access, even though normal traffic is forwarded through the bridge.
This article is not a general VLAN basics chapter. For planning zones, interfaces, VLANs, bridges, and LAGs, first refer to Configure Sophos Firewall Zones and Interfaces. Here, the focus is specifically on the bridge-VLAN special case after SFOS 22.
When this topic is relevant
The check is useful 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 via CLI VLAN tag configuration like
system vlan-tagor taken over from an old configuration. - Services of the firewall itself need to reach a tagged VLAN.
- After an upgrade, AD, DNS, authentication, monitoring, or management access only partially work.
- Normal client traffic through the bridge seems to continue running.
The last point is important: If the bridge continues to forward traffic between networks, the problem initially does not appear to be a bridge error. In practice, one quickly searches in the wrong place, such as firewall rules, DNS, STAS, or the domain controller.
Understanding affected traffic direction
Three types of traffic must be clearly separated.
| Traffic Type | Example | Why important? |
|---|---|---|
| Traffic forwarded through the bridge | Client in VLAN 100 communicates with server in VLAN 100 | Can continue to work. This does not prove that traffic to the firewall works. |
| Traffic to the firewall | Client uses the firewall as a DNS server or WebAdmin target | This traffic can be affected because it ends on the firewall. |
| Traffic from the firewall | Firewall queries AD, DNS, LDAP, RADIUS, NTP, or Syslog target | Also critical because the firewall itself is the sender. |
If only one application between two hosts is tested, the error is not reliably detected. The test must deliberately include a service that ends on the Sophos Firewall or is generated by the firewall.
Typical symptoms
Possible signs are:
- User-based rules no longer work reliably because AD, STAS, or LDAP are not stably reachable.
- DNS queries to the firewall fail from individual VLANs.
PingorHTTPSto local firewall services does not work from a VLAN, although the firewall rules seem plausible.- Monitoring or Syslog appears incomplete when the firewall must reach a target in a tagged VLAN.
- Packet Capture shows that traffic between end systems is visible, but services of the firewall itself do not respond as expected.
- After an SFOS-22 upgrade, the symptoms appear without any conscious changes to the switch or firewall rules.
Such symptoms should not be immediately addressed with broad Allow rules or Device Access permissions. First, it must be clear whether the interface design itself is affected.
Quick delimitation before restructuring
Before moving a bridge IP or creating new VLAN interfaces on the bridge, the cause should be narrowed down. Not every problem after an upgrade is automatically the SFOS-22 bridge-VLAN case.
| Observation | Likely area | Next sensible check |
|---|---|---|
| Only a single application between two hosts does not work | Firewall rule, NAT, target system, or return path | Test firewall rule and analyze dropped packets if there are drops |
| WebAdmin, DNS, or Ping to the firewall from a VLAN does not work | Device Access, Zone, local service, or bridge-VLAN special case | Check Zone and Administration > Device access, then test traffic to the firewall separately |
| Firewall does not reach AD, LDAP, RADIUS, DNS, or Syslog in the VLAN | Traffic from the firewall, routing, DNS, or bridge-VLAN special case | Test directly from the firewall configuration and check appropriate service logs |
| Normal client traffic runs, but services of the firewall itself do not | Bridge-VLAN special case becomes more likely | Check bridge design, old CLI VLAN tag configuration, and VLAN interface on bridge |
| There are no suitable log entries | Logging, wrong filter, local service, or unlogged 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 affects traffic from the firewall and can look different in bridge-VLAN problems than normal client traffic. The basics are in Set up DNS Request Routes on Sophos Firewall.
If the quick delimitation clearly points to local firewall services or traffic generated by the firewall, the restructuring should still be planned. A bridge correction without backup, maintenance window, and alternative access path is too risky for productive networks.
Document existing design
Before making changes, the current state should be documented. Particularly important are:
- Name of the bridge interface, for example,
br0. - Bridge members, i.e., involved physical interfaces, VLANs, RED interfaces, or LAGs.
- IP address of the bridge, if present.
- VLAN IDs running 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 the firewall must reach: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.
If the setup comes from an old migration, it should also be checked whether VLANs were set up via CLI configuration. This legacy is often no longer remembered if the firewall has only been updated over the years.
⚠️ Do not experiment spontaneously with bridge interfaces and VLANs during daily operations. A wrong change can affect management access, DNS, authentication, or entire client networks. Before correction, a backup, maintenance window, and alternative access path are needed.
Workaround: Create VLAN interfaces on the bridge
A practical way is to create VLAN interfaces in Network > Interfaces and use the bridge interface as the parent interface.
Examples:
| VLAN | New interface example |
|---|---|
| VLAN 100 | br0.100 |
| VLAN 200 | br0.200 |
The procedure 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 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 procedure:
- Create a backup.
- Document the 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 the zone consciously.
- Set the IP address on the VLAN interface if the firewall is to be a gateway or local service in this VLAN.
- Check Device Access for the zone.
- Check firewall rules and NAT rules.
- Validate with a test client.
The zone is not just order in WebAdmin. This decision influences 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 currently has the productive IP address
If the bridge currently uses the IP address that must be reachable in the VLAN in the future, special care should be taken. There are two clean variants for the restructuring: The bridge receives a different IP address, or the bridge remains without an IP address. The previously productive address is then assigned to the VLAN interface.
This is a change with a risk of failure. It should be clarified beforehand:
- Through which address is WebAdmin reached?
- Which clients use the firewall as the default gateway?
- Which DNS or DHCP settings point to this address?
- Which Device Access rules are attached to the previous zone?
- Is there a second management access from an unaffected network?
At remote locations, this change should not be planned without a local fallback. If WebAdmin and SSH run over exactly the affected bridge IP, an error can interrupt administrative access.
Check Device Access and 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 unexpectedly translated?
- Network > DNS or DNS Request Routes: Does the firewall reach the correct DNS or AD servers?
- Authentication > Servers: Are AD, LDAP, or RADIUS reachable after the change?
For local firewall services, Securely configure Device Access on Sophos Firewall is the appropriate in-depth article. For rule analysis, Test Sophos Firewall rule with Log Viewer and Packet Capture helps.
Validation after correction
A clean test should include more than a ping.
Test from the affected VLAN
From a client in the affected VLAN, check:
- Reach the 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 allowed management networks.
- Check a typical application or server connection.
- Check Log Viewer for the appropriate Rule ID and zone.
Test from the firewall
For traffic generated by the firewall itself, separate tests are needed:
- Test AD or LDAP server in Authentication > Servers.
- Check DNS resolution via the firewall.
- Check NTP, Syslog, or monitoring target if these services are in the VLAN.
- Use Packet Capture on the VLAN interface if it is unclear whether packets leave the firewall.
If STAS or user-based rules are affected, additionally check Set up STAS on Sophos Firewall. For SFOS-22 upgrades, this point also belongs in the SFOS 22 Upgrade Check.
Common mistakes
| Mistake | Effect | Better approach |
|---|---|---|
| Only test client-to-server traffic | Bridge appears healthy, although local firewall services are affected | Also test traffic to and from the firewall |
| Move bridge IP without a plan | WebAdmin, DNS, or gateway may fail | Prepare backup, maintenance window, and alternative access |
| Choose the wrong zone for the new VLAN interface | Rules, Device Access, and logs do not match | Choose zone according to security purpose, not habit |
| Open Device Access too broadly | Problem seems solved, but management services are unnecessarily accessible | Plan Local Service ACL specifically |
| Do not check switch port | VLAN arrives incorrectly or untagged | Validate tagged/untagged, Native VLAN, and trunk profile |
| Ignore old CLI configuration | Error remains unexplained after the upgrade | Document old design and migrate to WebAdmin VLAN interfaces |
Checklist
- Checked SFOS version and Known Issue relevance.
- Documented bridge interface, bridge members, and VLAN IDs.
- Clarified whether old CLI VLAN tag configuration was used.
- Identified affected services to and from the firewall.
- Backup and alternative management access available.
- Planned VLAN interface with bridge as parent interface.
- Checked zone, Device Access, firewall rules, and NAT rules.
- Conducted tests from the VLAN and from the firewall.
- Recorded result in change log or network documentation.