On Thu, Jun 28, 2012 at 1:35 PM, PC <paul4004@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.