VPN + AD + DNS

  • Thread starter Thread starter EdwardLHall
  • Start date Start date
E

EdwardLHall

Hello all:

Our XP laptop clients connect directly to our internal network as
domain members. When they are traveling around the world they use our
SonicWall VPN.

The client systems use DHCP to grab the most appropriate information
for their location, and are configured with static WINS addresses to
improve browsing of our internal network. The VPN software is
configured for split tunneling in order to minimize the bandwidth
demands on our VPN.

This configuration has always worked perfectly, until we migrated our
network to Active Directory, and abruptly discovered that these VPN
clients now require persistent access to our internal AD DNS server in
order to properly authenticate internal network resources.

After reading hundreds of posts I am still not clear if any sort of
tinkering with hosts or lmhosts can resolve this. We are considering
statically configuring the client DNS entries for a primary "Internet
root server" and a secondary "internal AD DNS server" but are looking
for better solutions.

Any advice is appreciated...
 
Some testing and talking to others with similar problems has lead me to
believe that DNS automatically uses the DNS servers on the interface with
the lowest cost gateway. So I would suggest you try this:

-- Configure the costs on the gateway metric for the VPN gateway to be
lower than that of the Internet connection.

HOSTS can't help with SRV records.

The suggestion of configuring DNS with public and then private won't work:
if the first DNS server cannot resolve the name the resolver doesn't then
use the second. The second is only used if the first doesn't respond within
the timeout period.

If these are business machines, I'd only use internal DNS; the internal DNS
can then resolve external. If they use the laptops outside of the VPN
though, you can't do this.

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Hello all:

Our XP laptop clients connect directly to our internal network as
domain members. When they are traveling around the world they use our
SonicWall VPN.

The client systems use DHCP to grab the most appropriate information
for their location, and are configured with static WINS addresses to
improve browsing of our internal network. The VPN software is
configured for split tunneling in order to minimize the bandwidth
demands on our VPN.

This configuration has always worked perfectly, until we migrated our
network to Active Directory, and abruptly discovered that these VPN
clients now require persistent access to our internal AD DNS server in
order to properly authenticate internal network resources.

After reading hundreds of posts I am still not clear if any sort of
tinkering with hosts or lmhosts can resolve this. We are considering
statically configuring the client DNS entries for a primary "Internet
root server" and a secondary "internal AD DNS server" but are looking
for better solutions.

Any advice is appreciated...
 
We have the exact same setup. Is the Sonicwall set to use the internal DNS
servers?

Ours worked before and after the AD migration, however our Sonicwall
provides the internal network with the DHCP address, DNS, etc.
 
I have never been a fan of using the 'networking hardware' to provide this
information. Sure, it works but I just feel that it would be better to use
Windows for your DHCP and DNS 'provider'. You loose some of the benefits of
using Windows for this. A person with whom I used to work always used the
Sonic Firewall to provide this information. While there were never any real
problems we were just not taking advantage of Active Directory Integrated
DNS and the like.

--
Cary W. Shultz
Roanoke, VA 24014
Microsoft Active Directory MVP

http://www.activedirectory-win2000.com
http://www.grouppolicy-win2000.com
 
Hmmm, if I reversed the DNS entries, so that the internal is the
primary and the external is the secondary, then they should work
correctly both in house and over VPN.

When they just need to connect to the Internet without VPN, the
internal "would not respond" and they would resolve using the
external...

I will be running tests next week and will let everyone know what I
discover...

Thanks.
 
Did you get this working?


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


Hmmm, if I reversed the DNS entries, so that the internal is the
primary and the external is the secondary, then they should work
correctly both in house and over VPN.

When they just need to connect to the Internet without VPN, the
internal "would not respond" and they would resolve using the
external...

I will be running tests next week and will let everyone know what I
discover...

Thanks.
 
OK, We found two solutions.

1. On the LOCAL AREA ADAPTER statically configure the PRIMARY DNS
server as the Internal AD DNS server and the SECONDARY DNS server with
any public server that is appropriate.

The only stability problem here is that roaming VPN users may not pick
up the most appropriate public DNS server for their location.

2. In our case, using a SonicWall VPN, we configured the Sonicwall to
pass out a virtual IP address, along with our internal DNS and WINS
servers, via DHCP to the VPN clients. This resolved the problem
entirely and allowed us to leave the LOCAL AREA ADAPTER without any
static configuration.

Hope this helps.
 
Thanks for the follow-up, I'm sure this info. will help others.

I'll also note this, as it's somewhat easier to manage than my solution ;-)


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

OK, We found two solutions.

1. On the LOCAL AREA ADAPTER statically configure the PRIMARY DNS
server as the Internal AD DNS server and the SECONDARY DNS server with
any public server that is appropriate.

The only stability problem here is that roaming VPN users may not pick
up the most appropriate public DNS server for their location.

2. In our case, using a SonicWall VPN, we configured the Sonicwall to
pass out a virtual IP address, along with our internal DNS and WINS
servers, via DHCP to the VPN clients. This resolved the problem
entirely and allowed us to leave the LOCAL AREA ADAPTER without any
static configuration.

Hope this helps.
 
Back
Top