Marko Apfel
Network

Troubleshooting VLAN Connectivity with Sophos XG

A layer-by-layer method for diagnosing unreachable VLAN gateways, clients, and services.

4 min read

The most productive troubleshooting session in this project began with a simple symptom: Sophos XG, using an address in one network, could not reach devices in several newly planned VLAN subnets. The solution was not one magic checkbox. It was to separate addressing, tagging, routing, and policy.

Start with an exact test statement

“The VLAN does not work” is too vague. Write down:

  • source device and IP address;
  • destination device and IP address;
  • protocol and port;
  • expected path;
  • observed result;
  • whether the test reaches the firewall itself or passes through it.

For example:

Source: Office client 10.0.20.50/24
Gateway: 10.0.20.1
Destination: MQTT broker 10.0.10.25
Service: TCP 8883
Expected: permitted by Office_to_MQTT
Observed: timeout

That statement immediately suggests specific checks.

Confirm physical link state on Sophos and the switch. Verify that the cable connects the port you configured—not merely the port you intended to use. Check interface counters and errors.

Port assignments changed during the project, so a cable map prevented old assumptions from surviving into the implementation.

Layer 2: VLAN membership and tagging

For the affected VLAN, verify:

  • it exists on the switch;
  • the client port is in the correct access/untagged VLAN;
  • the Sophos uplink is a tagged member;
  • the VLAN is allowed across every intermediate trunk;
  • Sophos has the same VLAN ID on the actual parent interface;
  • both ends agree about native or untagged traffic.

If a client cannot reach its own Sophos gateway, investigate this layer before adding inter-VLAN firewall rules.

Layer 3: address, prefix, and gateway

Inspect the client’s complete network configuration. A wrong prefix can be as disruptive as a wrong address.

The earlier overlap example is critical: 10.0.0.0/16 contains 10.0.10.0/24, 10.0.20.0/24, and many more. A /16 host may ARP locally for destinations that should be routed. Replace overlapping networks with disjoint subnets.

Verify that:

  • the client address belongs to the intended subnet;
  • the prefix is correct;
  • the gateway is the Sophos VLAN-interface address;
  • Sophos shows the interface as active;
  • no second router or DHCP server supplies conflicting information.

Routing: connected or remote?

Sophos automatically knows directly connected VLAN networks. Do not add static routes for those networks.

A static route is relevant only when the destination is behind another router. If Sophos owns 10.0.20.1/24, the route to 10.0.20.0/24 should already be connected. An unexpected static route or overlapping interface can send traffic in the wrong direction.

Also check the return path. A downstream device with a different default gateway may receive a packet but send its response elsewhere.

Policy: find the matching rule

Once the source can reach its gateway, inspect firewall policy:

  • correct source and destination zones;
  • correct network objects;
  • correct service object;
  • rule enabled and in the intended position;
  • logging enabled temporarily;
  • no earlier drop or more general rule matching unexpectedly.

Remember that WebAdmin access to Sophos itself uses device-access controls. A forwarding rule is not the correct fix for that case.

NAT: remove it from the internal equation

Internal VLAN-to-VLAN traffic normally needs no source NAT. If an internal rule unexpectedly masquerades clients, logs on the destination will show the firewall address instead of the client and return-path reasoning becomes harder.

For internet failures, test in stages:

  1. Can the client reach its VLAN gateway?
  2. Can it reach a permitted internal DNS resolver?
  3. Can it reach a public IP address?
  4. Can it resolve a public name?
  5. Which firewall and NAT rules match?

This separates routing from DNS.

Use packet capture at the boundary

A capture can answer whether the frame or packet arrives at Sophos, which interface receives it, and whether a reply leaves. Combine captures with switch counters and firewall logs:

  • nothing arrives: investigate client, access port, and trunk;
  • packet arrives on wrong interface or VLAN: investigate tagging;
  • packet arrives and is dropped: investigate policy;
  • packet leaves but no reply returns: investigate destination or return path;
  • replies return but the client sees nothing: investigate state, NAT, or downstream switching.

A compact checklist

Use this order to avoid random changes:

  1. Physical link and correct ports.
  2. VLAN exists everywhere required.
  3. Tagged/untagged behavior agrees.
  4. Client IP, prefix, gateway, and DNS are correct.
  5. Subnets do not overlap.
  6. Sophos interface is active and owns the gateway address.
  7. The routing table contains the expected connected route.
  8. The intended firewall rule matches.
  9. NAT is appropriate for the destination.
  10. Packet capture confirms where communication stops.

The general lesson is simple: troubleshoot from the nearest boundary outward. Do not broaden firewall rules until Layer 2 and Layer 3 are known to work.

References