technical contact at ATT Wireless

Joel Maslak jmaslak at antelope.net
Fri Jun 29 02:35:03 UTC 2012


On Thu, Jun 28, 2012 at 1:35 PM, PC <paul4004 at gmail.com> wrote:

> While you're at it, I've been also trying to complain about them using
> RFC1918 (172.16.) address space for the DNS servers they assign to their
> datacard subscribers.  Causes all sorts of problems with people trying to
> VPN in as the same IP range is used by me.

Which is why enterprises generally shouldn't use RFC1918 IPs for
servers when clients are located on networks not controlled by the
same entity.  Servers that serve multiple administration domains (such
as VPN users on AT&T - or on some random home Linksys box) probably
shouldn't be addressed using addresses that conceivably could be used
at the other end.  But I'm probably fighting a losing battle saying
that...

It's why at my last enterprise net admin jobs, I refused to establish
a site-to-site VPN session with organizations using RFC1918 space as
part of the tunnel definition (it's amazing how few organizations
wanted to use global IPs for inter-domain routing, but most came
around, although I had to loan IP addresses to several so they could
static NAT their servers behind them).  It's simple: If I wouldn't
accept IPs in that range over a public BGP peering, I didn't want it
over a private static route either.  I couldn't control what you did
for RFC1918, nor could you control what I did - so I exposed public
IPs, and expected you to do the same.  :)

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.




More information about the NANOG mailing list