Rotating an AWS VPN PSK: which tunnel drops, and when

Changing one AWS VPN tunnel pre-shared key drops that tunnel until both peers agree. Prove the alternate path first, then rotate one tunnel at a time.

The tunnel goes down the moment the two ends disagree about the pre-shared key, and it stays down until both sides carry the new value. That part is expected: AWS treats the change as an interruption of the selected tunnel, and the peer will not finish IKE while the keys differ. What surprises people is the second half. The other tunnel does not absorb the traffic on its own unless you checked that it can carry it. Rotate in this order and the outage stays inside one tunnel.

What actually happens when the key changes

ModifyVpnTunnelOptions rewrites the options for one tunnel, identified by its outside IP address. The tunnel is torn down and rebuilt, so IKE and IPsec negotiate from scratch with the new key. AWS states the interruption can run for several minutes, which is long enough for a routing protocol to notice. The other tunnel in the same connection is untouched by the call.

There is a second effect worth knowing before you send anything. The modify operation takes the full tunnel option set, so a field you leave out is written back with its default value. If you had tuned phase 1 or phase 2 lifetimes, or the dead peer detection settings, pass the current values in the same request or plan to restore them afterwards.

Read the current values first, then change one field. That sequence is the whole discipline of this task.

Match the AWS tunnel to the right peer first

The console labels tunnels by order, and your device does not use that label. Identify the tunnel by its outside IP address and match it to the peer stanza on the customer gateway. Tunnel 1 in a local configuration is not evidence that you are editing the tunnel AWS calls tunnel 1.

Start from the connection itself, which lists both tunnels and the key each one currently holds:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

The key that comes back is the one in use right now. Compare it with the peer configuration before you change anything, because a mismatch that already exists explains a tunnel that was never stable in the first place.

Make the other tunnel carry the traffic first

Two tunnels in one connection do not prove that your device has both configured, that both advertise the prefixes you need, or that traffic moves between them. Check the alternate tunnel's negotiation, its routes and a real application flow in both directions. With BGP, a live adjacency is useful evidence but not the same as confirming the prefixes. With static routing, confirm how the gateway picks the path and what it does when the preferred one disappears.

If the alternate cannot carry the workload, schedule the outage or repair the alternate tunnel before you touch the key. A status light on a console page is not a promise of uninterrupted service.

Rotate one tunnel, then verify with real traffic

With the alternate path proven, the sequence is short. Record the tunnel address, its peer and the non-secret settings, and keep a management path to the gateway that does not depend on the tunnel you are about to break.

  1. Update the customer gateway peer for the selected outside address, or prepare the change so it lands seconds after the API call.
  2. Send the modify call with the new key plus the current lifetimes and DPD values.
  3. Wait for IKE and IPsec to come back, then confirm the routes and the required prefixes.
  4. Push a representative application flow through that tunnel and watch both directions.

The tunnel is unusable while the ends disagree and while AWS applies the modification, so the peer update has to follow immediately rather than after lunch. Only when the changed tunnel carries real traffic should you repeat the procedure on the other one.

Stop if recovery or routing is still uncertain after the first tunnel. Two half-working tunnels are worse than one that you know works.

When recovery stalls, read the IKE side

A tunnel that stays down after both ends hold the new key is usually a policy mismatch that the rotation exposed rather than created. The proposals, the identity the peer sends and the traffic selectors all have to agree with the AWS side, and a value that survived an established tunnel can still be rejected during a fresh negotiation. Read the negotiation status and the message attached to it before you change the key a second time.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

If the change has to be undone, do not restore the old key merely because it used to work. Treat a compromised key as compromised and fix the negotiation instead. Finish with both tunnels verified and the secret inventory updated so each peer records which value it holds, and keep the AWS tunnel-options documentation next to the runbook.

Tënë sô zo