Dealing With ISPs That Use NXDomain Redirection? 264
Vrtigo1 writes "I work for a small company that has about 50 staff on the road relying on VPN back to our office at any given time. Many ISPs have implemented NXDomain redirection services that hijack DNS traffic to show you sponsored links and other related ads when you mistype a domain name. These services are incompatible with most VPN software, since they prevent the computer from resolving internal hostnames. Large ISPs typically provide an opt-out on their sponsored links page that immediately opts you out of the DNS redirection, but I've noticed that some smaller ISPs and CLECs have opt-out links that don't actually appear to do anything. I don't have a good solution for employees using these ISPs, and our employees are getting frustrated because the problem is becoming more prevalent and we can't fix it for them. I've tried calling a few of these smaller ISPs for help, but it's been like talking to a wall. Manually changing DNS servers works temporarily, but the user can't resolve internal hostnames when they connect to the office LAN again. Have you had to deal with ISPs using non-standard DNS servers? What is your solution?"
This is an easy one. (Score:5, Insightful)
If the small local ISP is screwing up, and refuses to respond in any useful way despite your best repeated efforts, it sounds like its time to take your business elsewhere, maybe to one of those large ISPs you mentioned. And make sure you tell them WHY. Who know, maybe the threat alone will be enough to get them to make a sudden change in policy for you, with a month or two of free service to boot.
Change VPN settings . . . (Score:5, Insightful)
to force use of internal DNS servers while connected.
Done.
Re:Change VPN settings . . . (Score:3, Insightful)
I guess I did not know there was an option not to use the internal servers.
Our unit has its own domain and dns servers. The zone does get replicated to the central dns servers, but we have to use the Fully Qualified Domain Name of our servers when on computers outside our unit.
Have the users try the full name of the server and see if that helps.
Re:This is an easy one. (Score:5, Insightful)
Stop filtering your DNS, or run a local cache. (Score:4, Insightful)
What's the benefit of blocking your internal DNS? You're firewalled off, or they wouldn't need the VPN. What's going on here is that you're doing something broken - you must have some kind of NXDOMAIN redirector running on the remote machine, and the ISP is doing something wrong, because its NXDOMAIN redirector is fooling your NXDOMAIN redirector. If you just follow the standards, the fact that they have a broken NXDOMAIN redirector wouldn't affect you.
Another option is to set up a DNS resolver that's reachable from outside your network, and also inside your network, but only answers for your internal names if the query comes from inside. Then configure all your VPN machines to always use that nameserver, and not use your ISP's nameserver.
Even if your ISP filters DNS and answers in place of your nameserver, you're okay, because as soon as the VPN is set up, all the queries will go across the VPN (since this server is on your local network). At that point you'll start getting answers for local domains because now the query is coming from a local (VPN) IP address.
This second solution is a bit more work, and of course being a DNS geek I'm biased toward just doing the right thing in the first place, so I recommend just opening up your DNS, but either way ought to work.
Re:Use Full Tunnels (Score:3, Insightful)
Re:Provide your own DNS? (Score:5, Insightful)
You're right. It all boils down to misconfigured VPN
Re:This is an easy one. (Score:5, Insightful)
Re:4.2.2.1 (Score:3, Insightful)
Re:Change VPN settings . . . (Score:2, Insightful)
This is an unethical practice (Score:3, Insightful)
Redirecting my web request to somewhere else, as far as I am concerned, is equivalent to re-routing my snail mail to their own office if someone has moved. That is not acceptable. I want a "not at this address" notice, nothing else.
Re:could someone explain what the issue is here? (Score:5, Insightful)
Even if all traffic goes down the VPN wire, it's probably making those requests to the same DNS servers OVER the VPN. Bust since it's still the same DNS servers, it still gets the same results.
The IT guy would have to intercept all DNS requests over the VPN and proxy them to his own DNS server. That's not a bad answer. Too bad I'm buried in the middle of this thread.
Re:Uhhh (Score:3, Insightful)
I wonder if the actual problem is this:
1. User goes to internal site, gets ISP not found page.
2. User goes "Whoops, need to turn on VPN". Turns on VPN
3. User hits refresh. Still goes to ISP not found page.
Is he sure this isn't an issue of just needing the user to close their browsers to clear the browser dns cache?
Re:could someone explain what the issue is here? (Score:3, Insightful)
Re:could someone explain what the issue is here? (Score:5, Insightful)
Some VPNs only route traffic meant for certain destinations through the VPN as one network interface and allow traffic to the public Internet use the actual established connection.
They should be checking the internal DNS servers first (which should not promulgate requests up to public servers), and then the public servers.
Doing in the other order sends internal information (server names) over the public network.
Your VPN is busted (Score:3, Insightful)
The first thing your secure VPN tunnel should be doing is altering the client's DNS profile to only use the DNS servers on the other side of the tunnel. Anything else is totally insecure.
Re:could someone explain what the issue is here? (Score:5, Insightful)
That's a hell of a security risk, having a client connected to both your internal network and external networks simultaneously.
Every corporate VPN I have ever used has, as part of its function, disabled all network interfaces other than the one it was using once a connection was established. In addition it would prevent any traffic from going through the "normal" connection. The idea was that a machine should never have connectivity to both the internal network and the outside world simultaneously.
The article poster doesn't need to fix their users' ISPs, they need to fix a horrifically broken and insecure VPN system.
Re:The solution is not to use DNS! (Score:2, Insightful)
Re:could someone explain what the issue is here? (Score:5, Insightful)
I'm not sure what your threat model is, but I suspect you are claiming one of two things: either that the VPN node might act as a router, forwarding packets around your firewall, or that the VPN node might be compromised and used as a stepping-stone onto your network.
In the case of the router vulnerability, this is something that you can control on the corporate side of things by simply not accepting packets down the VPN tunnel that don't come from the IP address that's the far endpoint of that tunnel. I'm not a VPN expert, but I would be surprised if this isn't how your VPN is configured by default.
In the case of the stepping stone, this is a fairly weak threat model, for two reasons. First, if your machine has been rooted, there's a good chance that it will phone home out through your firewall even if you route all internet access through the VPN. So it will be a stepping stone to your network anyway.
Second, if your machine has been rooted, and is running any sort of virus platform, it's going to try to infect machines on your network even if it doesn't have a link to the outside world. If you are genuinely concerned about threats originating on employee laptops, you shouldn't allow them to VPN into your network at all.
So the point is that forcing the VPN'd node to access the internet through your site is probably going to be a big inconvenience for your users (the kind of inconvenience they will hack around, possibly making you even more vulnerable) and it's not going to buy you any meaningful security.
Firewalls are great for slowing the spread of infection, and raising the cost of attacking you, but you really do need to secure every node as well, and if someone really wants to get past your firewall, and is willing to expend substantial effort to do so, you probably won't stop them without much sterner measures than the one you're advocating.
Re:could someone explain what the issue is here? (Score:4, Insightful)
Enforced at my work. In addition we don't allow user's personal machines onto the VPN. Since it's a company notebook on the VPN and all traffic goes through the VPN, we also enforce the internal AUP on remote users using the VPN. That means downloading a game patch will get you a stern talking to, downloading porn or torrents of wares, etc. will get you fired.
Again, this is all acceptable, because you are on company equipment (even if you are at home). If the case is that employees are being allowed to attach their personal equipment through the VPN to the company's internal network then I really hope you totally trust your employees, because one rogue could catastrophically hose you.
-nB
Re:could someone explain what the issue is here? (Score:5, Insightful)
And this is an excellent plan for convincing your users to only connect to the VPN occasionally. Good if you want to maximize security. Bad if you want to maximize productivity.
Re:Sounds like a configuration issue... (Score:1, Insightful)
If I have a typo configuring a TCP or UDP client, I need to know that. Hijacking the owner's DNS zone and sending me an IP address for some random machine that has never even tried to support the services I'm using? That's a recipe for troubleshooting hell. It's only tolerably awful for domains that offer nothing more than HTTP, and even there it violates the privacy of cookies and cache revalidation (but at least I'll know I've been screwed).