Connecting Sophos XG to a Managed Switch with an 802.1Q Trunk
Tagged, untagged, access, and trunk traffic explained through a Sophos XG homelab uplink.
The firewall can define perfect VLAN interfaces and still receive no traffic. The switch-to-firewall link must carry the same VLAN IDs with the same tagging assumptions.
Access ports and trunk ports
An access port normally belongs to one VLAN and presents ordinary untagged Ethernet to an end device. The connected printer, television, or PC does not need to know its VLAN ID.
A trunk transports multiple VLANs. Frames are marked with an IEEE 802.1Q tag so the receiving device can associate each frame with the correct logical interface.
In this design:
- end-device ports are access ports;
- the switch uplink to Sophos XG is a trunk;
- ports to VLAN-aware access points or hypervisors may also be trunks;
- the same VLAN IDs must be allowed end to end.
Tagged, untagged, and native traffic
Vendors use different terms. Cisco commonly speaks about access VLANs, trunks, and a native VLAN. HP ProCurve often describes VLAN membership as tagged or untagged. The concepts map roughly like this:
| Concept | Cisco-style wording | ProCurve-style wording |
|---|---|---|
| One untagged client VLAN | Access VLAN | Untagged membership |
| Multiple tagged VLANs | Trunk allowed VLANs | Tagged membership |
| Untagged VLAN on a trunk | Native VLAN | Untagged membership on uplink |
The syntax differs by switch model and software version, so the running configuration—not a memorized command—is the source of truth.
Decide whether the trunk needs untagged traffic
One recurring source of confusion was VLAN 1. If Sophos expects VLAN 1 as a tagged logical interface but the switch sends VLAN 1 untagged as its native VLAN, the two sides disagree. The same happens in reverse.
A clean design either:
- carries only tagged production VLANs on the firewall trunk; or
- explicitly documents the one untagged/native network and configures both ends accordingly.
“Whatever the switch does by default” is not a design.
Example intent
Assume Port6 on Sophos XG connects to switch port 17 and carries VLANs 10, 20, 30, and 40. The desired state is:
Sophos Port6:
VLAN 10 -> Infrastructure gateway
VLAN 20 -> Office gateway
VLAN 30 -> IoT gateway
VLAN 40 -> Home-automation gateway
Switch port 17:
tagged member of VLANs 10, 20, 30, 40
An edge port for an IoT device would be untagged/access VLAN 30. A frame arriving untagged on that edge port is internally associated with VLAN 30, tagged on port 17, and delivered to the Sophos VLAN 30 interface.
Limit the allowed VLAN list
Allow only required VLANs on a trunk. This reduces accidental extension of a network and makes troubleshooting easier. The VLAN must also exist in the switch database or configuration as required by the platform.
For a VLAN-aware Wi-Fi access point, the AP management network and SSID networks require their own consistent tagging model. An SSID-to-VLAN mapping does not help if that VLAN is missing from either the AP uplink or the firewall uplink.
A repeatable test
Test the trunk with one VLAN and one client before adding more:
- Choose a configured VLAN interface on Sophos.
- Confirm the same VLAN exists on the switch.
- Confirm it is tagged on the firewall uplink.
- Configure one edge port as untagged/access in that VLAN.
- Connect a client with a static address if DHCP is not ready.
- Verify the client can reach the Sophos gateway.
- Inspect switch VLAN membership and interface counters.
- Inspect Sophos logs or packet capture if the gateway remains unreachable.
If this path works, reuse it as the template for the remaining VLANs.
Common failures
VLAN missing from the trunk
The access port is correct, but the tagged frame is never sent toward the firewall.
Tagging mismatch
One side sends the VLAN untagged while the other listens for an 802.1Q tag.
Wrong parent port
The Sophos VLAN interface is attached to a different physical interface from the connected cable.
Old IP configuration on the parent
An unintended untagged subnet on the parent interface creates ambiguity during migration.
Incorrect client prefix or gateway
The Layer-2 path works, but the client decides that remote addresses are local or sends them to the wrong router.
Document ports physically
Port numbers changed during planning, which is normal in a real installation. I therefore record both ends of every important cable:
Sophos Port6 <-> Switch port 17: VLAN trunk
Sophos Port1 <-> administration connection: direct management
Labels on the devices are even better. Once the trunk is stable, the most sensitive remaining topic is the management network itself.