I'm trying to connect a client's network to our AWS data-centre, to allow access to a (previously publicly available) internal web-application.
At the moment we've got the VPN set up with dynamic routing to a new, empty VPC with a CIDR which doesn't conflict with the client's network, as our main VPC conflicts.
A few questions:
1) Does that CIDR need to be advertised or propagated to the client network, and how do I do that?
2) How I forward a client accessible IP address in that range to the internal IP address in the VPC containing the web-application?
3) And once done, how can I apply a security group to that VPN connection to limit access to that IP?
Or, am I going about this the wrong way?
If the VPN has dynamic routing, that means it's configured for BGP, so the CIDR for the VPC should be automatically advertised.
Here's where your plan breaks down.
For traffic to cross VPC boundaries, the VPCs have to have a peering connection. Peering connections do not support transit traffic.
A VPN connection to VPC B does not have access to the resources in VPC A, even when A and B are peered.
But, as the next point will illustrate, that's just as well.
You can't. The VPN connections provided by VPC are inherently trusted. They are allowed to access any instance within the VPC where the security group on the instance allows that access, which means all of your instances, including those with only private IP addresses, must be properly secured by their security groups, because the VPC VPN connection opens a large hole in the firewall for that trusted connection.
However... you don't have this problem because you've created a new VPC for the customer interconnection, and it can't transit across your peering connection into the main VPC.
Your solution to the issue in point 2 is to configure a proxy server in VPC B. Configure its security group to allow access from the permitted client IP, which solves point 3 since you have nothing else in this VPC. Point the proxy to the real service in VPC A, and allow its IP address to access the service via the appropriate security group in VPC A.
Maybe. :) The VPN service built-in to VPC appears to be intended for connections to fully trusted networks.
In my infrastructure, I only have one such VPN connection to a client's network, but in that instance, the entire VPC is on its own AWS account and has infrastructure that is dedicated to that one client.
In every other case where I have an IPSec tunnel to/from a client network, I don't use the VPN offering from VPC, since, as you can see above, it's really not ideal for this. Instead, I terminate the tunnel on an EC2 instance with an elastic IP, running Linux and Openswan and HAProxy.
The network numbering isn't a factor, because I assign a non-conflicting address to a secondary loopback interface on the gateway instance, and bind HAProxy to it. Whether I am accessing the customer's LDAP or HTTP service, or they are accessing one of mine, my machines see the instance's normal VPC-assigned IP address of the proxy, but the customer's network sees the fake non-conflicting address that the proxy uses for listening for connections from the client or establishing outbound connections to the client, inside the IPSec tunnel.
There is thus no actual IP routing taking place between my VPC network and the client's -- back-to-back TCP connections maintained by the proxy running on the gateway server is the only path from network to network, in thus scenario... which, incidentally, runs perfectly on the $5/month t2.nano instance class.