Resilient site-to-site VPN — AWS ↔ next-gen firewall

Overview

AWS offers two VPN tunnels per connection — one to a virtual private gateway or transit gateway on the AWS side, and one to a customer gateway on the remote side (a next-gen firewall, in this case). Each tunnel terminates in a different Availability Zone on the AWS side, so the loss of one AZ doesn't take the connection down.

This write-up covers a deployment that intentionally skips BGP: with only two tunnels and a small number of routed networks, static routing plus a firewall-side health check was simpler to build, document, and hand over than a dynamic routing protocol would have been. The trade-off is explicit — static routes don't fail over on their own, so failover is engineered separately using Policy-Based Forwarding (PBF) further down.

[ On-prem LAN ]
      │
[ Next-Gen Firewall ] ── Tunnel A (IKE/IPSec) ──►  [ AWS VPN Gateway — AZ 1 ]
      │                                                        │
      └──────────────── Tunnel B (standby) ──────────────►  [ AWS VPN Gateway — AZ 2 ]
                                                                │
                                                          [ VPC / workloads ]

Assumptions

• Firewall public IP: 203.0.113.60/29 (example — RFC 5737 documentation range)
• AWS VPN endpoint public IPs: 198.51.100.1 and 198.51.100.2
• Minimum crypto requirement for this environment: AES-128, SHA-1, DH Group 2 (matched to the oldest device in the path — raise this if every peer supports better)

1. AWS configuration

Create a virtual private gateway

In the VPC console, create a Virtual Private Gateway and attach it to the target VPC. This is the AWS-side anchor for the connection — it doesn't carry any tunnel configuration itself yet.

Create the Site-to-Site VPN connection

From VPC → Site-to-Site VPN Connections, create a new connection with:

• Target gateway type: Virtual Private Gateway (a Transit Gateway also works if you're centralizing multiple VPCs)
• Customer gateway: new, with the firewall's public IP and BGP ASN if using dynamic routing — leave routing as static for a non-BGP design
• Static routes: the on-prem CIDR blocks that should be reachable through the tunnel

10.10.1.0/24
10.10.2.0/24
10.10.3.0/24
10.20.1.0/25
10.30.1.0/24

2. Firewall configuration

IKE Crypto Profile

Define the ISAKMP (Phase 1) parameters — encryption, authentication, Diffie-Hellman group, and lifetime. This example matches the minimum requirement stated above; tighten it if every peer in the path can support stronger algorithms.

# DH Group
group2

# Encryption
aes-128-cbc

# Authentication
sha1

IPSec Crypto Profile

Defines the Phase 2 parameters — the encryption, authentication, and IPSec protocol mode that actually protects the data traffic once the tunnel is up.

IPSec Protocol: ESP
DH Group:       group2
Encryption:     aes-128-cbc
Authentication: sha1
Lifetime:       3600 seconds

IKE Gateways

An IKE Gateway represents one peer relationship — in this design, create two, one per tunnel. Both authenticate with a pre-shared key and negotiate in main mode.

Tunnel interfaces

Create two logical tunnel interfaces, set the MTU to 1427 (accounts for the IPSec/GRE overhead over a standard 1500-byte path), and assign each to the appropriate virtual router and security zone.

IPSec tunnels

Create two IPSec tunnels, one per tunnel interface, each pointing at its matching IKE Gateway and the shared IPSec Crypto Profile. Enable replay protection.

3. Failover: tunnel monitoring + Policy-Based Forwarding

A monitor profile watches an IPSec tunnel (or a next-hop device) and defines what happens when it becomes unreachable. Bind it to a PBF rule, and when the threshold trips, the firewall withdraws that PBF rule — traffic falls through to the next matching rule, which points at the healthy tunnel.

Create two PBF rules — one per tunnel — matching on source zone, source address, and destination address, each forwarding out its own tunnel interface with the monitor profile attached:

Source Zone:          Inside
Source Address:       10.10.1.0/24
Destination Address:  10.200.0.0/24

Action:               Forward
Egress Interface:     tunnel.2
Next Hop:             169.254.10.5
Monitor Profile:      AWS-TGW-MONITOR
Monitor IP:           169.254.10.5
Disable rule if next-hop/monitor IP unreachable: enabled

With this in place: one tunnel is active under normal conditions; if its Availability Zone or the tunnel itself goes down, the monitor trips, the PBF rule for that tunnel is removed, and traffic is re-forwarded out the second tunnel automatically. Remember to configure a static default/backup route on the firewall as well — PBF governs the primary path, but routing still needs a fallback.

Go-live checklist

• Virtual Private Gateway created and attached to the target VPC
• Site-to-Site VPN connection created with correct static routes
• IKE Crypto Profile and IPSec Crypto Profile match on both ends
• Two IKE Gateways created, each pointing at the correct AWS tunnel public IP
• Tunnel interfaces created with MTU 1427 and assigned to the correct zone/virtual router
• Monitor profile created and bound to both PBF rules
• Static backup routing configured in case both PBF rules are withdrawn
• Failover tested by disabling one tunnel and confirming traffic moves to the other