On Thu, Jun 28, 2012 at 7:35 PM, Joel Maslak <jmas...@antelope.net> wrote: > On Thu, Jun 28, 2012 at 1:35 PM, PC <paul4...@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. >
And, then there is this case where AT&T DSL is moving towards 10.x.x.x in the access network and they are guiding customers to move off that network in their LANs http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address- NET NET, ipv4 is getting more unreliable every day. Probably should consider IPv6 more strongly. And, getting AT&T to change their infrastructure is an exercise in futility. Your time is better spent changing your VPN to tunnel all traffic, including DNS, and / or moving to use an alternate DNS server. CB