Many Subnets in AWS VPN Connection

Hello @Lionel

To address the issue of adding multiple subnets to a VPN connection, let's break down the steps to understand the problem and find a solution.

Step 1: Understand the Error Message The error message indicates that the parameter LocalIpv4Cidr is not being accepted because it contains multiple CIDR blocks separated by commas. Typically, VPN configurations expect a single CIDR block for the local network.

Step 2: Check VPN Configuration Capabilities Verify if your VPN solution supports multiple local subnets. Some VPN solutions allow specifying multiple subnets, but the syntax or method might differ. Consult the documentation of your VPN provider to see if they support multiple CIDR blocks and how to configure them.

Step 3: Possible Solutions Single CIDR Block: If your VPN only supports a single CIDR block, you may need to summarize your subnets into a larger CIDR block that encompasses both (if possible).

Example: If possible, use a CIDR block like 10.0.0.0/16 to cover both 10.0.10.0/24 and 172.16.10.0/24, but this depends on your network design. Multiple VPN Connections: If summarizing is not feasible, consider creating separate VPN connections for each subnet.

This involves setting up individual VPN connections for 10.0.10.0/24 and 172.16.10.0/24. Advanced Configuration: Some VPN solutions allow advanced configurations using routing tables or policies to handle multiple subnets.

Check if your VPN supports such configurations and follow the specific instructions provided by your VPN provider.

Final Answer It is generally not possible to directly specify multiple subnets in a single LocalIpv4Cidr parameter if your VPN does not support it. Consider summarizing subnets, creating multiple VPN connections, or using advanced configuration options if supported by your VPN provider.

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

No, it isn't possible. AWS site-to-site VPN is designed as a route-based implementation, not a policy-based VPN, and it only supports one active security association (SA) in each direction at a time. In practice, it means that only one CIDR can exist at the SA level on each side of the connection.

This is specified as the first requirement in the customer gateway device requirements table in this documentation article: https://docs.aws.amazon.com/vpn/latest/s2svpn/CGRequirements.html

In your case, with the IP addresses spread across the whole IPv4 address space, you'll need to configure 0.0.0.0/0 as the CIDR for the on-premises/non-AWS side (LocalIpv4NetworkCidr) of your VPN connection.

You should also make sure that the on-premises side does the same. That's because if it's a policy-based VPN solution, which most typical firewalls use by default, and you configure the two separate CIDRs for the tunnel, when a client in 10.0.10.0/24 sends traffic to your VPC, the on-premises firewall would negotiate SAs for 10.0.10.0/24<=>VPC_CIDR. The AWS side would accept that, because 10.0.10.0/24 is a subset of 0.0.0.0/0. So far, so good.

However, when a client in 172.16.10.0/24 started sending traffic to AWS, the on-premises firewall would attempt to establish a second SA for 172.16.10.0/24<=>VPC_CIDR. To accommodate the request, the AWS side would tear down the earlier SA for 10.0.10.0/24<=>VPC_CIDR to make room for the new one, because only one SA pair (one in each direction) can be active at a time. If you had many active clients in both networks at the same time, the SAs would get established and torn down continuously, leading to intermittent connectivity for all traffic flows.

When 0.0.0.0/0 is configured for the on-premises side and the VPC's CIDR for the AWS side, the single SA established for 0.0.0.0/0<=>VPC_CIDR will be able to carry all traffic to and from AWS.

Setting up separate VPNs for each client network would work around the SA limitation for the AWS side, but in practice, it likely wouldn't work for the on-premises side, because from their point of view, the VPC CIDR would be the same for both tunnels. If there's a hard requirement to configure separate SAs for individual CIDR blocks, in the style of typical policy-based VPNs, the best solution would be either to find a third-party VPN appliance designed to work in a policy-based manner, or to set one up on an EC2 instance with open-source components based on Amazon Linux 2023 or Ubuntu Linux, for example. There are many third-party firewall/VPN appliances available in the AWS Marketplace.

AWS site-to-site VPN uses a route-based implementation, not a policy-based VPN, supporting one active Security Association (SA) in each direction at a time. Keep in mind that the Security Association (SA) is used to establish the tunnel, not necessarily for the Routing of allowed traffic.

Here is a great doc: Get started with AWS Site-to-Site VPN

You can use the same 0.0.0.0/0 subnet for both the CIDR for the customer gateway and the AWS side of the VPN connection.