CODEWITHSUNDEEP
amazon-web-servicesamazon-ec2vpcaws-nat-gateway
Ramesh
Ramesh

Reputation: 151

Connecting to internet through VPC peering

I have two custom VPCs for the purpose of Private & public access: VPC1(private) & VPC2(public). Each VPC has one subnet and further one EC2 with proper inbound rules. I am able to update software in public EC2 which is absolutely fine. Also, I am able to establish SSH connection between those two Ec2 after VPC-peering. But my goal is to use internet on pvt EC2 via public EC2. To achieve that I must add the NAT-gateway of VPC2 onto Route-table of VPC1(if I am not wrong). However, the NAT-gateway is not visible on VPC2-routetable. Though, I can use NAT-gateway from private subnet to public subnet in the case when they both subnets are within a single VPC. But, here I am struggling when they are in two different VPCs. Any advise pls ?

Upvotes: 3

Views: 3056

Answers (2)

forbiddenera
forbiddenera

Reputation: 158

It is not supported by AWS technically, but in theory should not be impossible. But it's gonna be a such a pain you might as well use a TGW instead.

VPC1 has public and private subnets Public - 10.0.0.0/24 Private- 10.10.0.0/24

VPC2 has a private subnet Private- 10.20.0.0/24

Vpc 1 and 2 are connected by peering.

Vpc 1 has a nat instance, 10.0.0.254 and 10.10.0.254 doing NAT from private to public. It also has a SNAT entry for the vpc2 cidr.

Now, you can't specify 0.0.0.0 as a route to the peering (well, you could, if aws doesn't stop you, but it will get stuck as it won't know where to go once in vpc1)

You can set a route for 10.10.0.254 or 10.10.0.0/24 to the peer from vpc2 and vice versa, same as you would do to access any regular service on vpc1 private subnet.

Now, your instance in vpc2 is going to get pushed a route table from aws, if you have an igw or nat in vpc2, then its internet route (0.0.0.0) will direct to that.

What you can do instead, and this is the pain point (especially if you want easily configurable ephemeral instances or say vpc cni managed pods) is set the default route ON the instance (in the OS) itself to 10.10.0.254.. then internet traffic will next hop to 10.10.0.254, vpc2s intrinsic router will push this over to vpc1 to hit that IP as a gateway. Now, that gateway will see the traffic coming from a different subnet than it is expecting to NAT (unless you use overlapping CIDRs) hence the need for an outgoing static nat from that CIDR. Your NAT instance will NAT it to the net and back. You will of course need to disable src dst check on the nat instance at least and maybe the vpc2 instances as well.

Personally, while this would work, I don't want to have to make custom configs to tell each instance to use the NAT instance IP instead of using the route provided over dhcp, especially when using eks and vpc cni custom networking and pods.

Thus it being easier to just use tgw. I don't think you can use AWS DHCP options either to force a custom default gateway like this.

You might think also that this wouldn't work because generally the default route points to the intrinsic router of the subnet (x.x.x.1) but I've tested with custom route tables (two public subnets on one instance) where the default routes were just assigned to an eni without a gateway set

So yes, it's technically possible. I don't think I'd recommend it due to the manual configuration requirements and while possibly a creative solution, it's not something that's going to win you any awards for best practices.

Another potential option is to expose your nat instances private eni into the 2nd vpc as a endpoint service.

I also highly doubt this would ever work with AWS NAT gateway, maaaybe with overlapping CIDR but otherwise probably not as you can't set the outgoing nat route or a vip..it could work with a custom nat instance however.

TL/DR; just use tgw probably, or overlay network (eg. Consul) or VPN or expose the eni as endpoint service in 2nd vpc

Upvotes: 0

Balu Vyamajala
Balu Vyamajala

Reputation: 10393

VPC peering connections do not support transitive routing. It violates source/destination check.

An instance will not receive any traffic if destination is not within the VPC. So, peered VPC without IGW will not be able to access internet with Peered VPC because when traffic does arrive into VPC which has IGW, source is outside VPC and destination is not local VPC (outside network).

Un Supported VPC Configuration is listed here

We can do it by routing traffic from private VPC to a proxy EC2 in public VPC(by disabling source/dest check on EC2) which forwards the requests to IGW.

We can also use Transit Gateway, here is a blog

Upvotes: 5

Related Questions