VPN routing validation — end-to-end, asymmetric, BGP convergence

Validating VPN routing requires end-to-end verification: the tunnel is up, the routing protocol has converged, the routes are installed, and the traffic actually flows. Each of these can fail independently, and the diagnostic must identify which one is broken.

This lesson covers the systematic validation flow for VPN routing, asymmetric traffic detection, BGP/OSPF convergence validation, and the production patterns.

The validation flow

End-to-end validation of VPN routing has five steps:

1. Tunnel state. The WireGuard or IPsec VTI is up.
2. Routing protocol convergence. BGP / OSPF / static routes agree on the routing state.
3. Route installation. The routes are in the kernel’s routing table.
4. Tunnel routing. Traffic to the remote network goes via the tunnel.
5. Traffic flow. End-to-end connectivity from a host behind R1 to a host behind R2 works.

Each step has its own verification command; the diagnosis proceeds until one of the steps fails.

flowchart TD
  A["Step 1: Tunnel state"] --> B["Step 2: Routing protocol"]
  B --> C["Step 3: Route installation"]
  C --> D["Step 4: Tunnel routing"]
  D --> E["Step 5: End-to-end traffic"]
  A -- "fail" --> F["Fix the tunnel"]
  B -- "fail" --> G["Fix the routing protocol"]
  C -- "fail" --> H["Investigate the routing table"]
  D -- "fail" --> I["Investigate route next-hop"]
  E -- "fail" --> J["Investigate end-to-end<br/>(firewall, MTU, etc.)"]

# Step 1: Tunnel state
vyos@R1:~$ show interfaces wireguard wg0
# Or for IPsec: show interfaces tunnel tun1
# Verify the interface is up, has the configured IP

# Verify the tunnel handshake (WireGuard)
vyos@R1:~$ wg show wg0
# latest handshake should be within the last 2 minutes

# Verify the IKE/ESP SAs (IPsec)
vyos@R1:~$ swanctl --list-sas
# IKE SA established; ESP SA active

# Step 2: Routing protocol convergence
vyos@R1:~$ show ip bgp summary
# BGP peer in Established state

vyos@R1:~$ show ip ospf neighbor
# OSPF neighbor in Full state

# Step 3: Route installation
vyos@R1:~$ show ip route 10.20.0.0/16
# Should show a route (via the tunnel)

# Step 4: Tunnel routing
vyos@R1:~$ show ip route get 10.20.0.5
# Should route via the tunnel interface (wg0 or tun1)

# Step 5: End-to-end traffic
vyos@R1:~$ ping 10.20.0.5
# Should succeed

vyos@R1:~$ mtr --report 10.20.0.5
# Shows the path; should be 1-2 hops (over the tunnel)

Asymmetric traffic detection

A common production failure: traffic works from one direction but not the other. Hosts behind R1 can reach hosts behind R2, but the reverse fails (or vice versa). Cause: asymmetric routing through stateful firewalls.

# Test from each direction
R1: ping 10.20.0.5       # Should succeed
R2: ping 10.0.0.5       # May fail with stateful firewall in the path

# Or:
hostA (10.0.0.50): mtr --report 10.20.0.5
hostB (10.20.0.50): mtr --report 10.0.0.50

# Compare the paths

The diagnostic:

1. traceroute -s <source-IP> <dest> from each end with the source IP explicit.
2. Compare the forward and reverse paths.
3. If they differ and a stateful firewall is in the path, the firewall may be dropping the return packets.

The fix:

• Align the routing to use the same path for both directions.
• Use stateless firewalls (rare in production).
• Use ECMP with consistent hashing.

BGP convergence over VPN

BGP convergence over a tunnel involves several steps:

1. The TCP session establishes (3-way handshake).
2. BGP OPEN message exchanges ASNs, BGP IDs, capabilities.
3. BGP KEEPALIVE messages confirm the session.
4. BGP UPDATE messages exchange routes.

The total time depends on:

• TCP handshake: ~ 1 RTT (typically 50-200 ms).
• BGP OPEN/KEEPALIVE: 1 RTT.
• BGP UPDATE flood: depends on the number of routes (a few seconds for thousands).

Typical VPN BGP convergence: 5-10 seconds for small networks; 30-60 seconds for large networks with many routes.

# Verify BGP convergence
vyos@R1:~$ show ip bgp summary
# Established (time should be > 1 minute)

# Check the routes received
vyos@R1:~$ show ip bgp
# Lists all BGP routes (received + locally originated)

# Check the route to a specific prefix
vyos@R1:~$ show ip bgp 10.20.0.0/16
# Should show the path via the peer

A clean BGP convergence:

• BGP session is Established within 30 seconds.
• Routes are exchanged within 1 minute.
• The routes are installed in the routing table.
• The remote network is reachable via the tunnel.

OSPF convergence over VPN

OSPF convergence over a tunnel:

1. OSPF hello packets establish adjacency.
2. OSPF exchange packets exchange the link-state databases.
3. OSPF computes the shortest path.
4. Routes are installed.

Typical VPN OSPF convergence: 5-15 seconds.

# Verify OSPF convergence
vyos@R1:~$ show ip ospf neighbor
# Peer in Full state (or 2-Way for DR-other)

# Check the LSDB
vyos@R1:~$ show ip ospf database
# Lists the LSAs

# Check the SPF computation
vyos@R1:~$ show ip ospf route
# Lists the OSPF-learned routes

A clean OSPF convergence:

• OSPF neighbor in Full state within 30 seconds.
• LSDB synchronized.
• Routes installed in the routing table.
• Remote network reachable.

End-to-end validation

A complete end-to-end validation checklist:

# 1. Tunnel state
vyos@R1:~$ show interfaces wireguard wg0
vyos@R1:~$ wg show wg0

# 2. Routing protocol
vyos@R1:~$ show ip bgp summary
vyos@R1:~$ show ip ospf neighbor

# 3. Route installation
vyos@R1:~$ show ip route 10.20.0.0/16
vyos@R1:~$ show ip route get 10.20.0.5

# 4. Tunnel routing
vyos@R1:~$ ping 10.10.10.2
# The peer's tunnel IP — should succeed

# 5. End-to-end traffic
hostA:~$ ping 10.20.0.5
# Should succeed

# 6. Asymmetric traffic check
hostA:~$ mtr --report 10.20.0.5
hostB:~$ mtr --report 10.0.0.50

# 7. Throughput check
hostA:~$ iperf3 -c 10.20.0.5 -P 4
# Should achieve close to link capacity

# 8. Sustained traffic check
hostA:~$ iperf3 -c 10.20.0.5 -t 300
# 5 minutes; should sustain throughput

Production failure modes

BGP session in Active state

The TCP session does not establish. BGP remains in Active or Idle state.

Cause: firewall blocking TCP 179; peer’s tunnel IP unreachable; configuration error.

Fix: open TCP 179 in the firewall; verify the peer’s tunnel IP; fix the configuration.

OSPF neighbor in Down state

The OSPF neighbor does not form. The peer remains in Down or Attempt state.

Cause: multicast not supported (broadcast network type with WireGuard); hello intervals mismatched; firewall blocking.

Fix: change network type to point-to-point; align hello intervals; fix firewall.

Routes are learned but not installed

The routing protocol learns the routes, but they are not installed in the kernel’s routing table.

Cause: route filtering (prefix-list deny); route map; next-hop unreachable.

Fix: correct the route filtering; verify the next-hop is reachable; verify the routing table with show ip route.

Traffic is asymmetric

Forward path works; reverse path fails. Cause: asymmetric routing through stateful firewalls.

Fix: align the routing; use consistent hashing; use stateless firewalls.

Throughput is lower than expected

The tunnel is up, routes are correct, but throughput is low.

Cause: MTU/MSS not configured; routing protocol using default timers; TCP not optimal.

Fix: configure MTU and MSS clamping; tune routing protocol timers; check TCP performance.

Recursive routing

The route to the peer’s tunnel IP depends on the tunnel itself. The routing is recursive; packets loop.

Cause: the peer’s public IP is in the allowed-ips / routing table.

Fix: ensure the peer’s public IP is NOT in the allowed-ips; only the tunnel subnet and remote subnets should be.

Rollback

# Capture the diagnostic output
show ip route | save /tmp/vyos-vpn-routing-validate-$(date +%s).txt
show ip bgp summary | save /tmp/vyos-vpn-bgp-$(date +%s).txt

# Roll back to a known-good configuration
configure
load /tmp/vyos-vpn-routing-backup-$(date +%s).conf
commit
save

The rollback restores the previous configuration; the state returns to the last known-good point.

Production discipline

Cross-course references

• Part LII-04 (LII-VyOS-Troubleshoot / subsystem by subsystem) covers the diagnostic methodology.
• Part XLIX-04 (XLIX-VyOS-Monitoring / VRRP telemetry) covers the monitoring integration.
• Part XLI-06 (XLI-VyOS-WireGuard / troubleshoot) covers WireGuard-specific validation.
• Part XLII-06 (XLII-VyOS-IPsec / troubleshoot) covers IPsec-specific validation.

Quiz