Transit Gateway Site to Site VPNs with Overlapping IPs across the Tunnel.

0

Hi, I am migrating some Site to Site IPSec VPNs from Cisco ASA to TGW however there are some overlapping IP ranges across the VPN tunnel. To overcome this issues, on the Cisco ASA, we have created some NAT statements for the overlapping IP addresses but as TWG doesn't support NAT, how can I move the VPNs from ASA to TWG with a overlapping IPs.

Regards Salman

asked a year ago431 views
3 Answers
0

See options 3 & 4 in this knowledge article https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-networks-with-overlapping-ip-ranges/

Option 3: Use multiple IP address ranges in VPCs Option 4: Hide subnets using Private NAT Gateway

profile pictureAWS
Matt_E
answered a year ago
0

Thanks Matt, options 3 & 4 talks about the traffic that is within/between VPCs. In my case VPN traffic will first hit the Transit GW and get decrypted, from then onward it will be sent to it's destination based on the TGW route table and at this point connectivity will break as source and destination IPs are same and I believe this will break connectivity. Happy to be corrected if that is not the case.

answered a year ago
0

This is a non-trival problem to solve because somewhere in the network you need a "device" that know how to communicate with two IP ranges that are the same. You can solve this by using a router (virtual or physical) which supports VRF-Aware NAT. A VRF is a virtual routing table; you create two on the router and they can each communicate with networks that are the same. Then the NAT process is there to convert packets from each side to the other.

In the AWS world you can do this but it's (again) not simple (nor is it simple on premises); but with the network design you've mentioned it isn't possible without significantly turning the network (and your administration processes) into knots.

Two options here:

  • If your application(s) support it, use PrivateLink. PrivateLink has equivalent functionality to VRF-Aware NAT - it doesn't mind if there are overlapping networks on either side of the service. In the VPC where the PrivateLink endpoint is you would use an IP range that doesn't overlap with the other networks.
  • Although it's way more work: Use a virtual router solution (that support VRF-Aware NAT, IPSEC VPN, GRE and BGP); host it in a VPC; connect your VPNs to it; connect the routers to Transit Gateway using Transit Gateway Connect; set up the VPN connections and the Transit Gateway connection as separate VRFs; perform VRF-Aware NAT on the router. This is a lot of work but if you are not in a position where you can renumber one of the networks this will work.

In both of these situations, applications on network X on premises think they are talking to network Y in AWS (but the intermediate systems - PrivateLink or router are converting from Y back to the X network in AWS) and applications on network X in AWS think they are talking to network Z but again the intermediate systems are converting Z to X.

Curiously, Z can be the same as Y if you're running a VRF-Aware router but it will makes discussing, troubleshooting and documenting things harder.

Sidenote: You can see why the blog post recommends renumbering over all the other solutions. It's simpler in the long run.

profile pictureAWS
EXPERT
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions