Routing VLAN Traffic through IPSec Tunnels: A Practical Guide

I will show a hands-on method to steer VLAN traffic from a remote site, through an internal IPSec Tunnel to head office, and out via a client IPSec Tunnel. I use concrete examples and commands you can copy. Keep your configs small and test each step. I prefer route-based tunnels and source NAT at the head office for predictable return paths.

Setting up your IPSec Tunnel for VLAN Traffic

Assessing your current network setup

• Map IP spaces. Note VLAN subnets, WAN public IPs and the client subnet the client expects. Example: remote VLAN 192.168.10.0/24, head office VLAN 192.168.10.0/24 (same number but separate L2), HO public 203.0.113.10, client public 198.51.100.1, client protected subnet 10.20.30.0/24.
• Find existing tunnel types. Is the client tunnel route-based (VTI) or policy-based (phase 2 selectors)? That changes how you push remote subnets through.
• Capture a baseline. Run traceroute and tcpdump at HO while a host at HO talks to the client. Save the capture for later comparison.

Determining VLAN configurations

• Make VLANs explicit on trunk ports. Keep the remote office VLANs isolated and routed, not bridged across your WAN unless you plan L2 stretching.
• Avoid IP overlap across sites. If remote and HO use the same subnet number, treat them as different segments. Use routing to carry the remote subnet between sites, not bridging.

Establishing IPSec tunnel parameters

• Use route-based tunnels where possible. They simplify adding subnets and sidestep strict phase 2 selectors. Create a tunnel interface and assign an IP. Example strongSwan conn snippet for policy-based:
  • leftsubnet=192.168.10.0/24
  • rightsubnet=10.20.30.0/24
• For route-based on VyOS/ASA/Linux:
  • Create the tunnel interface (vti0).
  • Add static route on HO: route 192.168.10.0/24 next-hop vti0 for traffic coming from remote.
• Match IKE settings with the client tunnel at HO: encryption, hash, DH group, lifetime. Keep lifetimes short for test, then lengthen.

Testing the IPSec connectivity

1. From a host in remote VLAN, ping the head office tunnel IP or a host in the client protected subnet.
2. Run show commands on both tunnel endpoints:
   • Linux/strongSwan: ipsec statusall, ip xfrm state.
   • Cisco/ASA: show crypto ipsec sa.
3. Use traceroute to confirm path: traceroute -s 192.168.10.5 10.20.30.10.
4. Take packet captures:
   • At HO before NAT, capture traffic matching source 192.168.10.0/24 and destination 10.20.30.0/24.
   • Confirm ESP packets on the wire and inner IP headers match expected subnets.

Monitoring traffic flow

• Add simple counters or logs on the tunnel interface and firewall rules. Track bytes in and out per subnet.
• Use periodic tcpdump scripts to confirm the correct tunnel carries the traffic after changes.
• Alert on SA flaps and mismatched MTU issues. MTU caused by double encapsulation is a common failure point. Reduce MTU on the VLAN gateway or enable MSS clamping on the FW.

Configuring Firewall Rules and Routing

Creating necessary firewall rules

• At remote office: allow traffic from VLAN subnet to the internal IPSec peer. Example rule set:
  • Allow: src 192.168.10.0/24 dst 203.0.113.10 proto ESP/UDP-500/UDP-4500 as needed.
  • Allow return traffic on the tunnel interface.
• At head office: permit the remote subnet on the internal tunnel termination and permit forwarding to the client tunnel.
• On the client tunnel: HO must present traffic from an IP the client has whitelisted. If that is only the HO public IP, make the traffic appear from that IP.

Implementing routing policies

• Use static routes or policy-based routing to prefer the internal tunnel for the VLAN subnet. Example:
  • At remote: route 10.20.30.0/24 via internal IPSec peer.
  • At HO: accept 192.168.10.0/24 from the remote IPsec peer and route toward the client tunnel interface.
• Avoid asymmetric routing. The reply path must follow the client tunnel back to the client. If replies try to exit via the general internet, the client will drop them.

Verifying NAT settings

• If the client only accepts traffic from whitelisted HO public IPs, apply source NAT at HO before the client tunnel:
  • NAT rule: source 192.168.10.0/24 translate-to 203.0.113.10 when dst in 10.20.30.0/24 and out interface is client_vpn.
• For route-based tunnels, place NAT before the egress tunnel or on the tunnel interface, depending on your appliance.
• Test NAT with tcpdump. Capture inner IPs and post-NAT traffic to confirm the source shows the HO IP.

Troubleshooting common issues

• Phase 2 selector mismatch: if traffic never escapes the first tunnel, check left/right subnets. Policy-based tunnels must include the remote VLAN subnet in phase 2.
• MTU drops and TCP stalls: lower MTU on VLAN gateway to 1400 or enable MSS clamping.
• Asymmetric routing: confirm routing tables on HO and client. Use traceroute from both ends.
• Logs and packet captures are your best friends. Capture both inner and outer headers to see where packets stop.

Ensuring compliance with client requirements

• Confirm the client’s allowed source IPs and acceptable NAT behaviour. Document any source NAT applied at HO.
• Keep a change log of route and firewall updates. Note times, IPs and config diffs.
• Present a short test plan to the client showing how remote VLAN traffic will arrive as expected and what source IP the client will see.

Final takeaways

• Use route-based IPSec where possible. It makes routing VLAN traffic simpler.
• At head office, apply source NAT if the client only accepts specific public IPs.
• Test with captures and traceroutes. Small changes and clear logs speed up root cause identification.
• Keep MTU and phase 2 selectors in mind. Those are the usual culprits when traffic stalls.