AWS Site-to-Site VPN: Inside, Outside and the LAN Prefix

Most AWS Site-to-Site VPN mistakes are address mistakes, and they are made before any packet moves. The tunnel's outside addresses reach the IPsec peers, the inside addresses form the routing link between them, and the protected prefixes are what that link is for. Copy one role into another and the tunnel comes up while nothing routes. Here is the read-check-configure sequence I use on a BGP customer gateway, with the values taken from the downloaded device configuration rather than from memory.

Three address roles, one tunnel

The outside addresses are public and belong to the IPsec peers: one per tunnel on the AWS side, and the customer gateway's reachable identity on your side, adjusted for whatever NAT arrangement you actually have. The inside addresses are private and belong to the logical link, which AWS documents as a /30 drawn from 169.254.0.0/16. The protected prefixes are the VPC, on-premises or transit networks that you route and advertise over that link.

Assigning a LAN prefix as the tunnel interface's address is the classic version of this error. The interface looks configured, the LAN is not advertised, and the far side has no route for it. The tunnel can even pass its own inside ping while every application name times out. The tunnel options reference lists the inside CIDR constraints, including the address range it must come from.

Read the values from the downloaded configuration

Download the configuration for your specific device model from the connection, then treat its address table as the source of truth. The console shows the same values per tunnel: outside IP, inside CIDR, and the BGP peer address on the AWS side. The two tunnels are separate objects with separate outside endpoints and separate inside /30s, even though both carry the same protected networks.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

If the downloaded file and the live console disagree, the file is stale. Re-download rather than editing addresses by hand, because a mismatch between the inside pair and the peer's configured neighbor is a silent BGP failure.

Build the link with the right address on it

On a Linux gateway the tunnel is a VTI or XFRM interface, and the inside /30 goes on that interface. Two tunnels mean two interfaces and two BGP neighbors, one per AWS endpoint. The convention AWS prints in the downloaded device configuration puts the virtual private gateway on the first address of each inside /30 and your customer gateway on the second, so you take the higher address and peer with the lower one. Nothing here needs a LAN address.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

If the file for your device model prints the opposite pairing, use its numbers and keep the rule: the address on the interface is yours, the peer address belongs to AWS. Getting this backwards produces a tunnel that never reaches Established, because the neighbor you configured is the address your own interface already holds.

Keep the mark and the VTI key aligned with whatever the IKE daemon uses to bind a child SA to the interface, or traffic arrives on the tunnel with no interface to land on. Check the MTU against the path and against the IKE daemon's own settings instead of copying a number from another site.

Verify BGP before you verify routes

IPsec coming up proves the peers agree on a security association and nothing else. The BGP session is a separate negotiation over the inside link, so read the neighbor state and the prefix counters, then compare them with what you intended to advertise.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

State Established with zero prefixes received is a policy or advertisement problem, not a tunnel problem. Repeat the whole check on the second tunnel; a working tunnel one tells you the addresses are plausible, not that tunnel two was configured at all.

Follow a routed packet, then stop

Once the session carries the prefixes, test the route in both directions from the gateway: source address, next hop, and the security policy that permits the traffic. A BGP session can be up while the specific prefix your application needs is filtered, summarised away, or pointed at the wrong interface.

Reachability Analyzer is the AWS-side tool that takes a source, a destination and a path, and reports which component in a supported configuration blocked it. Use it to test the path from the VPC to your customer gateway address, not from an application host. It analyses configuration and does not send a packet through an on-premises firewall, so keep its verdict separate from your own interface counters and packet captures.

Record the outside pair, the inside /30, and the advertised prefixes for each tunnel in one table. That table is what makes the next change reviewable.