Skip to content
VenerableNetworks
SpecialtyProSite-to-Site VPNAWS VPC

Lab 07: The Tunnel That Was Up And Went Nowhere

A Site-to-Site VPN reports available, the tunnel reports UP, and the static route for the on-premises prefix is listed on the VPN connection. No traffic passes in either direction, and every page in the VPN console is green.

Debugging time
~35 min
Reading time
12 min
Reported by
Network Engineering
Tier
Specialty
INC-1402SEV-3InvestigatingOpened 2026-09-18 08:05 UTC

New Site-to-Site VPN shows both endpoints healthy but carries no traffic

Reported by Network Engineering

The VPN to the branch site was built yesterday. Connection state is available, the tunnel is UP, and the static route for 192.168.0.0/16 is configured on the connection — we can see it in the console.

Nothing works. The branch cannot reach the application host in the VPC, and the application host cannot reach anything at the branch. It is not slow or intermittent; it is silent in both directions.

We have checked the customer gateway address, the pre-shared key, and the security groups. The security group on the AWS side permits the entire branch prefix on all protocols, so it is not that. The tunnel would not be UP if the IPsec configuration were wrong.

What you are working with

Two VPCs in one account. The second one stands in for the branch office: it runs a Libreswan host as the customer gateway, so the whole path is reproducible without hardware.

Starting state — the tunnel is up and one side has no route for the other
VPC aws 10.50.0.0/16 Attached: Internet gateway, VPN gateway. AZ a contains aws 10.50.1.0/24, default route 0.0.0.0/0, holding App host. VPC on-premises 192.168.0.0/16 Attached: Internet gateway. AZ a contains onprem 192.168.1.0/24, default route 10.50.0.0/16 → eni, holding IPsec host.VPN connectiontunnel 1 UPVPC aws 10.50.0.0/16AZ aawspublic10.50.1.0/24App hostlistens on 8080VPC on-premises 192.168.0.0/16AZ aonprempublic192.168.1.0/2410.50.0.0/16 → eniIPsec hostsource/dest check off0.0.0.0/0Internetgatewaytooling onlyVPN gatewayattachedInternet gateway

Read the two route tables against each other. The branch side sends 10.50.0.0/16 at the IPsec host's interface so the daemon can encapsulate it. The AWS side's table holds a default route for tooling and its implicit local route, and nothing else — the virtual private gateway is attached to the VPC and no route table on this diagram references it.

  1. EC2

    Application host (AWS VPC)

    10.50.1.x — replying to 192.168.1.x

  2. RTB

    Subnet route table

    local 10.50.0.0/16, default → internet gateway

    Dropped — no route for 192.168.0.0/16 at all — the virtual private gateway is attached but nothing propagates its routes into this table

  3. GW

    Virtual private gateway

    attached, tunnel UP — never consulted

  4. DEST

    Branch host

    192.168.1.x

The tunnel's health is irrelevant to this hop. A route table decides whether traffic is ever handed to the gateway, and this one has no entry for the branch.

ResourceConfiguration
AWS VPC10.50.0.0/16, subnet 10.50.1.0/24
Branch VPC (simulated)192.168.0.0/16, subnet 192.168.1.0/24
Virtual private gatewayAttached to the AWS VPC
VPN connectionipsec.1, static routes only, one tunnel configured
VPN connection route192.168.0.0/16 — present
AWS route tablelocal plus a default route to the internet gateway
sg-awsAll protocols from 192.168.0.0/16

The branch side is a second VPC with an IPsec daemon on one instance. It is scaffolding, not the subject.

Scope and constraints

  • In scope: why traffic does not pass while the connection and tunnel report healthy.
  • Out of scope: the pre-shared key, the customer gateway address, IKE parameters, and both security groups. The security group on the AWS side deliberately permits everything from the branch prefix so it cannot be a second cause.
  • Static routing, not BGP, so there is no BGP session to blame and no route advertisement to count.
  • This lab does not need a working tunnel to diagnose. The evidence is all in the AWS API. If your tunnel is down, you can still complete the diagnosis and the fix; you just cannot watch traffic flow at the end.

Deploy the broken state

cd lab-07-vpn-route-propagation
terraform init
terraform apply
 
# Shell on the branch host
aws ssm start-session --target "$(terraform output -raw onprem_instance_id)"