AWS VPN Local and Remote CIDR: Which Side Is Which?

You open the Site-to-Site VPN options, see two CIDR boxes labelled local and remote, and reach for the address you think of as local: the VPC. That is the reverse of what the API means. In the connection options, LocalIpv4NetworkCidr names the customer-gateway side, and RemoteIpv4NetworkCidr names the AWS side, because the customer gateway is where the connection is built from. The console never says this out loud, and nothing rejects a plausible-looking swap.

Start at the API call, not the console label

Read the connection options reference once, all the way through, and notice that every option is written from the customer gateway's point of view. That is not an accident of naming. The tunnel is described as it appears to the device that terminates it on your side, so local means the network behind your gateway and remote means the network behind the AWS gateway. Both IPv4 and IPv6 fields follow the same rule.

Write the two labels on a sticky note before you type anything: customer side, AWS side. Then map your addresses onto them.

A worked example with the roles attached

Suppose the on-premises prefix is 10.20.0.0/16 and the VPC prefix is 10.60.0.0/16. The options read exactly as the roles suggest, with the on-premises range in the local field:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

Now hand the same pair to whoever configures the peer device and watch the trap fire. On many firewalls, local means the interface the tunnel terminates on and remote means the far end, which is the opposite mapping for the AWS side. Both people can be correct and still produce a tunnel that never completes, because the two vocabularies describe different endpoints.

Repeat the exercise in the peer's terminology on paper, with both CIDRs and both labels, before either device is touched.

Defaults are not a design

The same reference lists 0.0.0.0/0 as the default for both IPv4 fields, with analogous IPv6 values. Seeing those values in an existing connection tells you the field was never narrowed, not that an internet exit has been configured. Route distribution, the subnet route table and the security controls still decide what traffic can actually cross; the CIDR values only describe which ranges the tunnel is willing to select.

Replacing a narrower value with the default is therefore not a compatibility trick you can apply when a tunnel misbehaves. It widens the selector and leaves every other layer exactly as it was.

The peer device uses the other viewpoint

Once the AWS side is clear, the peer configuration is where most of the remaining confusion lives. A device that asks for a local network and a remote network is describing its own interface as local, so your VPC range goes in its remote field and your on-premises range goes in its local field. If it instead asks for traffic selectors in pairs, you are writing both directions explicitly and the labels matter less than the pairing.

Read the device's field help rather than its field names. Vendors reuse the same two words for three different concepts.

Then check the tunnel status for both phases, since a mismatched selector usually shows up as a phase-two failure while phase one sits happily established.

Change the options like a change, not like documentation

Editing connection options on a live VPN can interrupt service, so treat it as a maintenance action with a window, a rollback value and a note of who is affected. Capture the current options first, including both CIDR fields and the tunnel options, so a revert is a paste rather than a reconstruction.

After the change, verify from the AWS side and from the peer: a source in each range reaching a destination in the other, in both directions. A single ping from one side proves one selector.

Then update the connection documentation with the roles written out, so the next person does not have to rediscover that local means yours.