Re: technical contact at ATT Wireless

[Tyler Haske <tyler.haske () gmail com>]

> 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.