Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[ekgermann at cctec.com (Eric Germann)]

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.