0

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?

1 Answer 1

3

1) Does that CIDR need to be advertised or propagated to the client network, and how do I do that?

If the VPN has dynamic routing, that means it's configured for BGP, so the CIDR for the VPC should be automatically advertised.

2) How I forward a client accessible IP address in that range to the internal IP address in the VPC containing the web-application?

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.

If either VPC in a peering connection has one of the following connections, you cannot extend the peering relationship to that connection:

• A VPN connection [...]

http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/invalid-peering-configurations.html

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.

3) And once done, how can I apply a security group to that VPN connection to limit access to that IP?

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.

Or, am I going about this the wrong way?

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.

3
  • I've just been asked to create a similar setup for one our customers (link their datacenter to our VPC so we can access their internal services over private IP space), and because giving them access to our prod VPC, even though all connections would theoretically be initiated on our end, sounded scary and I was hoping I could use a sort of 'DMZ' VPC. Do you have any pointers to how you configured HAProxy? Are you using kernel-enabled transparent proxy?
    – Karen B
    Jul 1, 2016 at 6:15
  • Yes, connecting a customer directly to your production VPC would qualify as scary. A "DMZ" VPC would work, with HAProxy inside, since it would be able to talk across peering. I've seen some of your posts and it seems like you really know your stuff, so if you haven't used HAProxy, I think you'll find it pretty intuitive. It can do HTTP-aware and raw TCP proxying and the logs are extremely useful. I tend to drop it in between poorly-instrumented legacy systems, just for the visibility it can add. Also stats and timeouts. I don't use transparent, that's always seemed like the wrong solution. Jul 1, 2016 at 23:33
  • @KarenB my contact information is also on my profile (now... I had it on SO, but wasn't on SF). If you're like to go into more detail on some specifics, I probably have some suitable boilerplate config to get you started. You'll want to start with 1.6.6. If you're using SSL and terminating it or originating it on the proxy, you'll need to go slightly newer to avoid a regression from a fix that quieted a valgrind warning that may have been spurious. Jul 1, 2016 at 23:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .