Routing VLAN traffic through IPSec tunnels

Routing VLAN traffic through IPSec tunnels

Steer VLAN traffic from a remote site through an internal IPSec tunnel to head office, then out through a client IPSec tunnel. Keep the configs small and test each change. Route-based tunnels and source NAT at head office make the return path easier to predict.

Setting up the IPSec tunnel for VLAN traffic

• Map the IP spaces. Note the VLAN subnets, WAN public IPs, and the client subnet the client expects. For 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.
• Check the tunnel type already in use. Is the client tunnel route-based (VTI) or policy-based with phase 2 selectors? That changes how the remote subnet is pushed through.
• Capture a baseline. Run traceroute and tcpdump at head office while a host there talks to the client. Keep the capture for comparison later.
• Make VLANs explicit on trunk ports. Keep the remote office VLANs isolated and routed, not bridged across the WAN unless L2 stretching is the plan.
• Avoid IP overlap across sites. If the remote and head office use the same subnet number, treat them as separate segments. Carry the remote subnet with routing, not bridging.
• Use route-based tunnels where possible. They make it easier to add subnets and avoid strict phase 2 selector matching. Create a tunnel interface and assign an IP.
• For policy-based strongSwan, the matching remains explicit:

  leftsubnet=192.168.10.0/24
  rightsubnet=10.20.30.0/24

• For route-based setups on VyOS, ASA or Linux, create the tunnel interface such as vti0, then add a static route at head office for 192.168.10.0/24 via vti0 for traffic coming from the remote site.
• Match the IKE settings with the client tunnel at head office: encryption, hash, DH group and lifetime. Keep lifetimes short for testing, then lengthen them once the path works.

Testing the IPSec connectivity

1. From a host in the remote VLAN, ping the head office tunnel IP or a host in the client protected subnet.
2. Run the status commands on both tunnel endpoints:

   ipsec statusall
   ip xfrm state
   show crypto ipsec sa

3. Use traceroute to confirm the path:

   traceroute -s 192.168.10.5 10.20.30.10

4. Take packet captures at head office before NAT. Match traffic with source 192.168.10.0/24 and destination 10.20.30.0/24, then check that ESP packets are on the wire and the inner IP headers match the expected subnets.

Monitoring traffic flow

• Add counters or logs on the tunnel interface and firewall rules. Track bytes in and out per subnet.
• Use periodic tcpdump scripts to check that the right tunnel still carries the traffic after changes.
• Watch for SA flaps and MTU problems. Double encapsulation often causes stalls. Lower the MTU on the VLAN gateway or enable MSS clamping on the firewall.

Configuring firewall rules and routing

• At the remote office, allow traffic from the VLAN subnet to the internal IPSec peer. A typical rule set allows source 192.168.10.0/24 to destination 203.0.113.10 over ESP and UDP/500 and UDP/4500 as needed, plus return traffic on the tunnel interface.
• At head office, permit the remote subnet on the internal tunnel termination and allow forwarding to the client tunnel.
• On the client tunnel, head office must present traffic from an IP the client has whitelisted. If that means the HO public IP, make the traffic appear from that IP.
• Use static routes or policy-based routing so the VLAN subnet prefers the internal tunnel. At the remote site, route 10.20.30.0/24 via the internal IPSec peer. At head office, accept 192.168.10.0/24 from the remote peer and route it towards the client tunnel interface.
• Avoid asymmetric routing. Replies must leave through the client tunnel and return the same way. If they try to go out via the general internet, the client will drop them.
• If the client only accepts traffic from whitelisted HO public IPs, apply source NAT at head office before the client tunnel:

  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 the NAT before tunnel egress or on the tunnel interface, depending on the appliance. Check it with tcpdump and confirm the source changes to the HO IP after NAT.

Troubleshooting common issues

• Phase 2 selector mismatch: if traffic never leaves the first tunnel, check the left and right subnets. Policy-based tunnels must include the remote VLAN subnet in phase 2.
• MTU drops and TCP stalls: lower the MTU on the VLAN gateway to 1400 or enable MSS clamping.
• Asymmetric routing: check the routing tables on head office and the client. Run traceroute from both ends.
• Logs and packet captures are the quickest way through it. Capture both inner and outer headers to see where packets stop.

Client requirements

• Confirm the client’s allowed source IPs and acceptable NAT behaviour. Record any source NAT applied at head office.
• Keep a change log of route and firewall updates, with times, IPs and config diffs.
• Show the client a short test plan that proves how the remote VLAN traffic arrives and what source IP the client sees.
• Use route-based IPSec where possible. It makes VLAN routing simpler.