- Newest
- Most votes
- Most comments
Can you explain how is 10.20.20.20 is configured with ping is successful? Local IPv4 Network CIDR (IPv4 VPN connection only) The IPv4 CIDR range on the customer gateway (on-premises) side that is allowed to communicate over the VPN tunnels. Default: 0.0.0.0/0
If you put in there a specific CIDR/mask, it will only allow that CIDR to generate traffic back on the VPN. In your case, you are only allowed to PING network in your on-premises with IP addresses from 10.20.20.20/X range. Did you try 10.0.0.0/8 for your Local IPv4 Network CIDR?
Keep the default values for Local and Remote IPv4 0.0.0.0/0 and test it. if it works, then start narrowing down the network address to an address that summarize all networks you want to reach over the VPN. For your case, both 10.10.10.10 and 10.20.20.20 can be reached if you allow 10.0.0.0/11
On the AWS side, I changed the local IPv4 network CIDR to 10.20.20.20 in the "Modify VPN connection options" menu. I also had to change the remote IPv4 network CIDR to the internal IP address of my NAT gateway's Elastic IP address otherwise the tunnel would not go up
Yassine, I just updated my answer. Keep the default values for Local and Remote IPv4 0.0.0.0/0 and test it. if it works, then start narrowing down the network address to an address that summarize all networks you want to reach over the VPN. For your case, both 10.10.10.10 and 10.20.20.20 can be reached if you allow 10.0.0.0/11
@Amer, I cannot contact both IPs at the same time if the local IPv4 CIDR range is 0.0.0.0/0. In any case, shouldn't the customer gateway configure the traffic selectors / security associations to match the local IPv4 CIDR range set on AWS?
Ideally, a local IPv4 network CIDR of 0.0.0.0/0 should allow you to reach both on-prem IP addresses. I would recommend checking the encryption domain configured on the customer gateway as well as confirming whether they are really running a route based VPN on the Cisco customer gateway. If it is indeed route based then they could use encryption domain as 0.0.0.0/0 for both sides which would resolve this issue.
There are a few things you can try to reach the two non-contiguous IP addresses on the on-premises network using a single VPN tunnel:
Verify that your customer gateway device supports and has asymmetric routing enabled. With asymmetric routing, the device can route traffic for different IP prefixes over different tunnels, allowing both addresses to be reachable over the single VPN connection.
Check the routing configuration on the customer gateway device. Make sure it has a route configured to send 10.10.10.10/32 traffic over one tunnel interface and 10.20.20.20/32 traffic over the other.
On the AWS side, ensure the transit gateway has VPN endpoint connection options enabled. This allows AWS to load balance traffic for different prefixes across both VPN tunnels.
Confirm the transit gateway route table associated with the VPC attachment has static routes defined for both 10.10.10.10/32 and 10.20.20.20/32 with the next hop as the transit gateway.
Verify connectivity at layer 3 by pinging between the IP addresses and checking the route tables show the traffic taking the expected paths over the tunnels.
Relevant content
- asked 3 years ago
- asked 5 years ago
- asked 4 months ago
- asked 25 days ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated a year ago
FYI, my EC2 instances are in a private subnet and internet traffic goes through a NAT gateway.
I had to change the VPN tunnel's remote IPv4 network CIDR to the private IP address of the NAT gateway's Elastic IP address otherwise the tunnel would not go up