Do Two Sites Need Matching VLAN IDs for a Site VPN?
Matching VLAN IDs cannot fix a routed site VPN: the tunnel carries IP prefixes, so the address plan and selectors decide reachability, not switch tags.
Matching VLAN numbers at two offices feels like it should help a site-to-site tunnel, and it changes nothing about what the tunnel carries. A VLAN ID labels an Ethernet broadcast domain inside one building; the tunnel forwards IP packets between gateways. Two sites can run completely different VLAN numbering and still route to each other, and two sites can run identical VLAN numbering and still be unable to reach each other. The variable that decides reachability is the address plan.
The myth: matching VLAN IDs at both ends
The belief comes from a reasonable place. Inside one building, two ports in the same VLAN can talk and two ports in different VLANs cannot, so the VLAN number looks like the thing that grants connectivity. Across a routed tunnel there is no shared Ethernet segment for the tag to describe, and the gateways never exchange VLAN labels.
What the tunnel needs is a pair of address scopes that do not overlap and a policy that permits the traffic between them. Change the VLAN at either office and the tunnel keeps working, because nothing in the tunnel configuration referenced it. That is the test that settles the argument: renumber a VLAN, leave the addresses alone, and watch the tunnel stay up.
The reverse test is equally informative. Give both offices the same subnet and no amount of matching VLAN numbers will make an address unambiguous.
What the tunnel actually carries
IPsec protects IP packets according to a policy expressed in addresses, protocols and ports. The IPsec architecture describes those selectors at the IP layer, which is several layers above anything a switch tag describes. When a packet enters the tunnel it has already left the VLAN; the tag was consumed by the local switch.
Policy-based and route-based designs differ in how they choose the tunnel, not in what they can carry. A policy-based peer matches traffic selectors and sends matching packets into the tunnel. A route-based peer routes traffic at a tunnel interface and lets the routing table decide. Both still negotiate a protection scope, so a route that points at the tunnel does not widen what the peers agreed to protect.
That distinction explains a common half-failure: the route exists, packets enter the tunnel, and the far side drops them because the negotiated selectors never included that prefix. Reading the installed policies shows which scope actually took effect.
ip xfrm policy
ip route show
swanctl --list-sasThe overlap that actually breaks
Two offices with distinct subnets route cleanly through a tunnel, and their VLAN numbers are irrelevant. Two offices with the same subnet do not, because a request for a given address has two possible meanings and the routing table can only pick one. Renumbering one site is the clean fix, and it is usually cheaper than the alternatives once the DNS and firewall changes are counted.
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
When renumbering is impossible, a deliberate translation design can present distinct address views to each side. That means one-to-one mapping, matching selectors, DNS entries that reflect the translated view and return routing that survives the rewrite. It is a supported design with real operational cost, and it is not what changing a VLAN ID does.
Matching VLAN numbers at both ends is sometimes a coincidence of a shared template, and treating that coincidence as the cause of a working tunnel leads to the wrong change when something later breaks.
One job per layer, written down
The local switch decides which ports share a broadcast domain, and its VLAN numbering is local bookkeeping that no other site needs to know. The gateway authenticates the peer and enforces the negotiated protection scope. The routing table decides where a decrypted packet goes next, and the access policy decides whether that packet should have been allowed at all.
Keeping those jobs separate is what makes changes safe. A VLAN renumber at one office touches the local switch, the DHCP scope and possibly a firewall zone, and it does not touch the tunnel. A prefix change touches the tunnel selectors, the routes on both sides and the access policy, and it does not touch the switch tags.
Return routes, private DNS and application identity requirements are separate jobs again, and none of them arrives by copying a VLAN number from the other site. A design document that lists reachable prefixes and permitted services survives a switch refresh; one that lists VLAN numbers does not.
Confirm the local picture with the bridge tooling before you assume a tag reaches the tunnel.
bridge vlan show
ip -br addr
ip route get 10.62.0.20When layer-2 extension is the real requirement
Some designs genuinely need Ethernet behaviour across sites: a legacy application that relies on broadcast discovery, a migration that must keep an address while a machine moves, or a protocol that embeds layer-2 assumptions. Those cases call for an overlay or a bridged service that carries the frames, and then VLAN membership, loop prevention and failure handling become end-to-end concerns.
That is a much larger failure domain, and it should be a deliberate choice rather than the accidental result of trying to make a file share work. An ordinary file server, database or web application needs an authorized IP path, and it will be happier without a stretched broadcast domain underneath it.
Write the VPN contract as reachable prefixes plus permitted services, and record the VLAN label only where local operations need it. Each office can then renumber its own switching without turning every change into a tunnel redesign.