tl;dr Is there any way to route traffic from 172.20.0.100 to 200.0.0.100 in the diagram via 10.0.0.6 ?
I have a setup where we have an existing AWS VPC (172.20.0.0/16) with a number of hosts in it. We are attempting to setup a VPN to a vendor who have the following constraints:
- Source host must be different from the VPN peer
- Source host must have public IP address or vendor issued private address
To this end, the vendor have allocated us a range of 10.0.0.0/28. We have setup a second VPC in the account with this network because we were unable to add the 10.0.0.0/28 range to our existing VPC. Seems to be a limitation where you can only add additional ranges to a VPC with the same prefix (10, 172, 192).
There is a route in VPC 2's route table that sends all traffic for 200.0.0.0/24 via the internal interface (eni) of the IPSEC VPN host.
The VPN connection from 10.0.0.6 to 200.0.0.100 works.
VPCs 1 and 2 are peered, and routes and SG changes have been made such that all machines in 172.20.0.0/16 can connect to all hosts in 10.0.0.0/28 (All Traffic, not specific UDP / TCP / ICMP rules). So 172.20.0.100 can connect to 10.0.0.6.
Is there any way to set this up such that:
- All traffic to 200.0.0.0/24 from VPC 1 is routed via the internal NIC on the VPN host
- All traffic to 200.0.0.0/24 from VPC 2 is routed via the internal NIC on the 10.0.0.6 host, so that it can be NAT'd ?
Thanks in advance !
You have an interesting scenario. I will cover five methods of supporting the routing of two networks with another network in between.
You asked two questions:
1) For Q1, is your VPN host a router that supports adding route entries? If so, then maybe (see the bottom comments on METHOD 3). If no, then review METHOD 3 or METHOD 4.
2) For Q2, look at METHOD 4 to configure a proxy server on that instance. However, don't use that instance for anything else, just proxy serving. The size and type will depend on how much traffic you need to route.
However, if your vendor will only allow source addresses from 10.0.0.0/28 then METHOD 4 (proxy server) is probably the only solution.
Now for the various methods. Not all are acceptable based upon your requirements. I am listing all of them just in case you can modify your environment.
METHOD 1: The simplest solution is to have your vendor allow a VPN from VPC 1 to their data center and allow 172.200.0.0/24. You could shrink this to /28 by creating a subnet 172.200.X.0/28 (which only allows for 11 hosts)
METHOD 2: Move your resources from VPC 1 to VPC 2. Same subnet limitations apply.
METHOD 3: In VPC 2 you need to configure an instance running routing software (R1). This instance needs addresses within the /28 subnet. Then from VPC 1 you create an entry in the route table for traffic going to 200.0.0/24 send it to R1. A similar entry needs to go in the vendors route table to send traffic for 172.20.0.0/16 to R1. Both networks (VPC 1 and vendor) will need routes for 10.0.0.0/28. You might be able to configure the routing on your IPsec VPN Host (is this an instance running VPN software or VGW?). Note: Your vendor will have to allow your 172.20.0.0/16 addresses (or a subnet) into their network as this will be the source IP address and not the 10.x.x.x.
METHOD 4: Setup a Proxy Server in VPC 2 and route traffic to the proxy server. This means the traffic originates in one direction VPC 1 -> Vendor (or the reverse setup). The vendor will not be able to originate traffic to VPC 1. You could do port mapping on the proxy server to support Vendor -> VPC 1. However, with port mapping you will not be able to map all ports for all addresses (just the ones that that you configure).
[EDIT with METHOD 5]
If the VPN Host in VPC2 is a AWS virtual gateway (VGW), then you can setup a route to VPC 1 (more than one VPC can use the same VGW). This may be the simplest solution.
I think the easiest and most effective way would be to use AWS Route Tables. It should be sufficient to add an entry with destination 200.0.0.0/24 to NIC-id|Instance-id on the subnets in the VPC where you've your VPN Instance. And 200.0.0.0/24 to 10.0.0.1/32 on the other VPC.
As the VPC's are already peered that should do the job. And the beauty of such solution is, that there is no fiddling/configuring on the instances.
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
Be aware that there is a
sourcs destination check
option at EC2 level which could be a pitfall on AWS. You most likely need to disable that on your ipsec host (10.0.0.1).