- Más nuevo
- Más votos
- Más comentarios
It should be possible to achieve what you need using a Transit Gateway.
The existing Site-to-Site VPN connection can remain unchanged and continue functioning as before to connect the on-premises network in the MAIN account to the VPC.
To enable connectivity from the second on-premises network to the same VPC subnet, you can:
Create a new Site-to-Site VPN connection between the second on-premises network and the Transit Gateway.
Attach the VPC in the MAIN account to the Transit Gateway and configure appropriate route tables so traffic destined for the VPC subnet routes through the Transit Gateway.
Similarly, attach the VPC in the SECONDARY account to the Transit Gateway and configure routing.
This allows both on-premises networks to connect privately to the VPC subnet, without requiring any changes to the existing Site-to-Site VPN. The Transit Gateway acts as a central hub, avoiding conflicts due to overlapping IP ranges.
Thanks. The issue I am majorly facing with this is now is the ip range they need my end to communicate with is not overlapping(mine is 10.2.1.0/24 while theirs is 10.83), the actual problem is that they have that ip range of my subnet existing on their on prem environment and might cause routing issues for them. I have been exploring this transit gateway option and setting it up but have been trying to understand how a transit gateway will actually help them point to my subnet.
Transit Gateway can't help solve an overlapping IP address problem. You can perform some operations using Private NAT Gateway in conjunction with Transit Gateway but I wouldn't generally recommend that solution without a significant amount of planning.
As the author of this blog post about overlapping IP address ranges my strong recommendation is "don't do that" - but I also understand that sometimes that isn't an option. However, please read and consider carefully because maintaining connectivity between two networks with the same IP address range is expensive in the long run in terms of both technology and people.
Note that PrivateLink or VPC Lattice (which was released after I wrote that blog post) might be a valid option here but it depends on the application(s) and how they interact on the network.
Yeah, attaching a private gateway to the subnet will surely disrupt what I have running which I am trying to avoid for now. From considering the content of your article, the only option that seems a bit doable is the privateLink,, however I am really familiar with it. Also, VPC lattice isnt an option here.
Contenido relevante
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace un año
Hey Olive, Before I can answer your question I need to clarify you question. Does the new on-prem location has an overlapping IP block with the subnet in the VPC ? or does it have overlapping with the existing on-prem location ?
Hi Azeem, the new on prem ip I need to point to does not clash with either my aws subnet nor the existing on prem location. The new on prem location has my aws subnet range existing in their on prem environment meaning, they will run into issues when they need to point to it or setup firewall rules