2008r2 RRAS VPN issue due to poor domain naming. Any ideas?

Question

We have a domain with 900+ clients and 250+ workstations that has the name of the domain the same as it's public domain name (we'll call it example.org).

I'm trying to set up RRAS VPN, and it works beautifully as far as connecting goes. The problem rears it's ugly head when you want to do anything beyond connecting. I can ping everything by IP on the internal network just fine, and I can even connect to things as long as I do it by IP. However, whenever I want to connect to something, say dc1.example.org, it tries to resolve it on the local dns and then fails.

NSLookup works, insofar that it will find the ip for dc1, but it always uses the VPN DNS server last, instead of first (which is the way you would think it should go).

Example:

Client:
IP: 123.123.123.123
DNS: 8.8.8.8

RRAS:
Public IP: 208.123.234.150
Internal IP: 10.99.99.254
Internal DNS: 10.0.0.10

Client can connect to the server using PPTP, authenticate, receive proper IPs like 10.99.99.20, can ping the gateway for the route 10.99.99.1, and can ping the DNS server 10.0.0.10. Resolving is the only thing that doesn't work. And without name resolution, this is a non-workable solution to deploy.

Ideally we'd just change our internal domain name, and be done with it. However, I've already spent 160 hours in the last two weeks at work, and don't feel like pulling another 40 hour weekend when things go bad, and they would go bad (we've had everything from Exchange servers decide to corrupt AD, to machines catching on fire, to phones deciding to call emergency numbers when people hung up). Does anyone have an easy fix that will work for 50+ very technologically challenged people?

Extra info:

RRAS Server is running 2008R2, AD Servers are running 2003r2 and 2008r2, DNS servers are running 2003r2, DHCP server is running 2003r2.

DC1 = AD + DNS + DHCP DC2 = AD + DNS DC3 = AD

RRAS = RRAS only

Clients will be XP, 7, OSX, Linux, etc. The problem I'm trying to resolve seems to happen on XP machines (90% of the clients, at this point)

Answer 1

You've got a mess there. I'll have to file this away as yet one more reason why an AD domain shouldn't use a public-facing Internet domain name.

Block outgoing DNS requests from all machines except your internal DNS servers at the firewall. Demand that all VPN clients are configured not to use split tunneling. Their DNS requests to off-site DNS servers will traverse the VPN and be blocked at the firewall, forcing them to fall back to the internal DNS servers.

Of course, there's nothing you can do to enforce that clients aren't using split tunneling.

A domain-rename is going to be your best bet for a long-term fix because there isn't really much of anything you can do on the server side to control client-side behavior. If the client is using the wrong DNS server there really isn't anything you can do to make it stop.

Answer 2

Server 2008 supports conditional forwarding, so set up a forward for example.org to the dns on the other side of the VPN. This only requires permission on your side of the network.

Then other option (which I prefer) is to set up a secondary dns zone on your side of the VPN and sync it with the remote side (this requires permissions on both sides).

Both scenarios involve losing access to the www version of the domain.