> RFC1918 and VPN becomes non-scalable fast when you connect to lots of > different organizations - it doesn't take long before two > organizations you connect to both want to use 172.16.0.x/24 or > 10.0.0.x/24 or 192.168.0.0/24, or similar). The same logic goes for > VPN clients - if one end is potentially using RFC1918, the other end > better not use it. Since you can usually only control one end of the > VPN for road-warrior VPN, it's best to make that end not use RFC1918. > Otherwise you may find you need to route 192.168.x.y, but that just so > happens to be the user's default gateway, name server, printer, or > other key device. Of course having another set of NAT addresses for > CGN will solve everything (yes, that's sarcastic, but I can predict > how they'll be used to "solve" this type of problem). > > Just because "it usually works" doesn't mean using RFC1918 addresses > for left and/or right subnets in a VPN is a good idea.
My workplace solves this by just NATing again. It isn't the best solution but it does work. Put aside a 10.0.0.0/16 and whenever you have a NATed network you want to connect a VPN to on the edge just static NAT the addresses to make them unique again. Their 172.16.x.x becomes your 10.2.x.x. I dunno about 'not scalable'. I guess if your connecting to thousands of networks it won't work well, but for a a few hundred it works well enough. I'm sorry you don't like it, and I know IPv6 will wash all this away soon enough, but where I'm working we have no plans to implement IPv6, or require our vendors/partners to readdress their networks to get a VPN up.
