Hi, Would anyone happen to know a contact at ATT wireless that would be able to help diagnose a DNS issue? we are seeing the DNS record for boston.com intermittantly resolve to the wrong IP address, but I am having trouble getting through to the correct people through normal support. Thanks Mike
I wish you the best of luck. 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. Why they don't use public IP space belonging to them for DNS servers, I do not know. -Paul On Thu, Jun 28, 2012 at 11:15 AM, Mike Devlin <mdevlin@aisle10.net> wrote:
Hi,
Would anyone happen to know a contact at ATT wireless that would be able to help diagnose a DNS issue? we are seeing the DNS record for boston.com intermittantly resolve to the wrong IP address, but I am having trouble getting through to the correct people through normal support.
Thanks
Mike
I'm sure they use carrier grade NAT, yes. However, nothing would prevent them from using a unique public IP assigned to them for their DNS servers like others do. Using RFC1918 space for a routed destination of an ISP service (DNS) is particularly problematic for many VPN client configurations with corporate address range overlap. -Paul On Thu, Jun 28, 2012 at 1:40 PM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Thu, Jun 28, 2012 at 3:35 PM, PC <paul4004@gmail.com> wrote:
Why they don't use public IP space belonging to them for DNS servers, I do not know.
they have the same addresses used in multiple VRF's? so much simpler for them to manage...
On Thu, Jun 28, 2012 at 4:20 PM, PC <paul4004@gmail.com> wrote:
I'm sure they use carrier grade NAT, yes.
I'm sure it's not 'carrier grade', but it does play one on tv...
However, nothing would prevent them from using a unique public IP assigned to them for their DNS servers like others do.
sure. they could do lots of things.
Using RFC1918 space for a routed destination of an ISP service (DNS) is particularly problematic for many VPN client configurations with corporate address range overlap.
of course, but you aren't supposed to be doing that on their network anyway... so says the nice man from sprint 4 nanogs ago. -chris (yes, I realize that people use the 'wireless' network for all manner of things that the 'wireless carriers' are not always happy about, but hell, they do give out 'internet protocol' connections, they ought to expect people to 'use' them, eh?)
On Thu, Jun 28, 2012 at 1:50 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
of course, but you aren't supposed to be doing that on their network anyway... so says the nice man from sprint 4 nanogs ago.
That, and if you are tunneling in, it's good practice to forward over any DNS traffic as well (or all, depending on the application). That way, if you have internal names or special resolvers setup, you'll hit that as well. Cheers, jof
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.
On Thu, Jun 28, 2012 at 7:35 PM, Joel Maslak <jmaslak@antelope.net> wrote:
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.
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... 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
On Jun 28, 2012, at 10:35 PM, Joel Maslak <jmaslak@antelope.net> wrote:
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...
I've worked at places that do some combination of all public, all private and a mix.. Usually the places that work best have all public as they avoid mtu and other issues that arise. I expect the enterprise world to start coming around in the years to come to understand how they have damaged networking for the companies. - Jared
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.
On Jun 29, 2012, at 10:37 AM, Tyler Haske wrote:
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.
Just because there are no plans, this doesn't mean you shouldn't bring it up. Even if its a "radar"/"future" issue for their networking team, it does raise the profile in the asks with others. - Jared
On Fri, Jun 29, 2012 at 10:51 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Jun 29, 2012, at 10:37 AM, Tyler Haske wrote:
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.
Just because there are no plans, this doesn't mean you shouldn't bring it up.
Even if its a "radar"/"future" issue for their networking team, it does raise the profile in the asks with others.
- Jared
Let it be known that I hate NAT with the burning passion of a million suns. But I'm the junior in my workplace, and this is the advice of the head honchos. I can easily see both sides of this. I would say with a few implementations, (maybe 25 or fewer) NATing isn't that difficult. Granted we both know that NAT breaks basically everything and makes troubleshooting a TON MORE FUN. But plenty of people out there (my workplace included) would argue this till the cows come home.
Let it be known that I hate NAT with the burning passion of a million suns. But I'm the junior in my workplace, and this is the advice of the head honchos. I can easily see both sides of this. I would say with a few implementations, (maybe 25 or fewer) NATing isn't that difficult.
Granted we both know that NAT breaks basically everything and makes troubleshooting a TON MORE FUN. But plenty of people out there (my workplace included) would argue this till the cows come home.
Yep... While this environment would benefit greatly from deploying IPv6 on both sides of the connection, the reality is that NAT is easy enough and works well enough for the implementor that they will leave it's various pain points for the people that have to deal with it after implementation and they won't select IPv6 as a solution because it would involve slightly more pain up front. However, the networks on both sides of these equations will have to face IPv6 in the relatively near future anyway, unless they aren't actually talking to the internet in which case, it doesn't really matter what addresses or protocols they use. Owen
participants (9)
-
Cameron Byrne -
Christopher Morrow -
Jared Mauch -
Joel Maslak -
Jonathan Lassoff -
Mike Devlin -
Owen DeLong -
PC -
Tyler Haske