On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <ekgermann@cctec.com> wrote:
Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications.
Users access apps in the VPC, not the other direction.
The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space.
Initially, I was looking at doing something like (example IP’s):
Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24)
Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer).
In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?”
Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do.
I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine.
From the operator community, what are the downsides?
Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out.
The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side.
Thoughts and thanks in advance.
Eric
Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the "public cloud" and put them in the on-premise "private cloud" because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB