>I'm >assuming, for the moment, that the internal servers you're having >problems reaching are on the same subnet?
Yep, no complexity there. >Also, I have to question why you have two sets of DNS servers. Why not >make static entries in your local DNS for your clients? It's more work >up front, but it can be automated, with dnscmd, I think. You make it sound like I did it on purpose, but the other org's DNS is established by default on the PPP adapter when the VPN is connected. And I'd prefer to have their DNS resolution available when I'm connected, vs. other workarounds. A single entry in the hosts files for my AD domain to avoid this problem is a very minor and acceptable workaround. Carl -----Original Message----- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: Thursday, December 11, 2008 8:41 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Thu, Dec 11, 2008 at 6:45 AM, Carl Houseman <c.house...@gmail.com> wrote: > "Use default gateway on remote network" is NOT checked for the VPN TCP/IP > configuration. Dang. That eliminates my best guess. > I agree with the recommendations about diagnosing in a methodical way. Here > are the results. If you don't have a lot of time for reading, skip to the > bottom couple paragraphs, there's a new realization there. > > First, I mapped a total of 6 drives to the 2 local servers in 3 different > ways: > One to each server with \\servername (this was done by default) > One to each server with \\servername.mydomain.com > One to each server with \\ip.add.re.ss Excellent! > Then I connected the VPN (with VPN gateway server credentials). > Then I mapped a drive to a remote AD DC (using remote domain credentials). OK. > My IPCONFIG /ALL results showed (truncated to include only relevant info): > > Windows IP Configuration > Primary Dns Suffix . . . . . . . : mydomain.com > Node Type . . . . . . . . . . . . : Hybrid > IP Routing Enabled. . . . . . . . : No > DNS Suffix Search List. . . . . . : mydomain.com > PPP adapter VPN-to-Customer-Network: > Connection-specific DNS Suffix . : > Physical Address. . . . . . . . . : > Autoconfiguration Enabled . . . . : Yes > IPv4 Address. . . . . . . . . . . : 10.1.7.33(Preferred) > Subnet Mask . . . . . . . . . . . : 255.255.255.255 > Default Gateway . . . . . . . . . : > DNS Servers . . . . . . . . . . . : 10.1.1.176 > 10.1.1.172 > Ethernet adapter Local Area Connection: > Connection-specific DNS Suffix . : mydomain.com > Autoconfiguration Enabled . . . . : Yes > IPv4 Address. . . . . . . . . . . : 192.168.55.129(Preferred) > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > Default Gateway . . . . . . . . . : 192.168.55.1 > DNS Servers . . . . . . . . . . . : 192.168.55.10 [my DC/Local-DNS] > > I checked DNS resolution at this time. I could resolve FQDN's of both my > domain and the remote domain. I've noticed that, when there are multiple > connections each with their own DNS, DNS's of each connection will be tried > in turn until one resolves the request. You want to see route print because > you still don't trust the gateway setting I already confirmed? Heh. No need to get testy, there youngster... > Active Routes (just the important ones): > Network Destination Netmask Gateway Interface Metric > 0.0.0.0 0.0.0.0 192.168.55.1 192.168.55.129 25 > 10.0.0.0 255.0.0.0 10.1.5.135 10.1.7.33 21 > And tracert was giving 1 hop to local servers, 2 hops to remote network > servers, such as 10.1.1.172. OK. > The first results came 20-30 minutes later, when the first mapped drives > were lost. Which ones? > Those mapped to \\ip.add.re.ss ! > The other 4 were still working. At this point I re-checked pinging by by > FQDN to both local and remote servers, and both were working and resolving > correctly, even after an ipconfig /flushdns. Tracert unchanged. > > About 8 hours later, but with no activity, the other mapped drives were > still good. I started doing some work and suddenly, the two drives mapped > to \\servername were exhibiting the problem AT THE SAME TIME, which is > unusual (typically the member server is the first to go by a margin of more > than a couple minutes). The drives mapped to \\servername.mydomain.com > still worked. Results of ping, tracert, ipconfig, route print, all > unchanged. > > When I went to disconnect (NET USE /D) the drive mapped to my local DC with > \\servername, it told me "There are open files and/or incomplete directory > searches pending on the connection to m:." Curious. I forced it, and tried > a "net use m: /home" to restore it. That failed: "The user's home directory > could not be determined." My user account specifies \\server\share for my > home directory. LIkewise, "net use m: \\server\share" got "The password or > user name is invalid for \\servername\share" and prompted for a password. > It was trying to use the VPN gateway credentials. I then tried "net use m: > \\servername.mydomain.com\share" and that worked. > > But it gets weird here. I went into ADU&C (from the same Vista machine) and > changed my user account profile's home directory to > \\servername.mydomain.com\share. I then tried "net use m: /home" again. > "The user's home directory could not be determined." Went to another > machine where I was already logged on, disconnected m: and then "net use m: > /home" - worked. WTF? > > This has been interesting experiment, though little is explained. > > Just to re-cap, through all this, DNS, ping, tracert, route print, ipconfig > /all results have remained the same, even after ipconfig /flushdns. > > One thing that now occurs to me, my AD domain name is also my public domain > name (split DNS), with the public one pointing to a public IP for Internet > E-mail purposes. So if something was trying to work off that top level > name, it would get a result from the remote network's DNS server and come up > with an IP address that isn't reachable. But that's not affecting tools > such as ADU&C running on the same platform. > > Can I force DNS resolution to consult my local DNS instead of the remote > network's DNS... and what will happen if I do that. Hmmm..... checking > HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind, I see: > > \Device\{1BF6FDBF-63AF-4A12-9A68-BFD7D06BB920} > \Device\NdisWanIp > \Device\{277E3FE6-F44A-473C-B5F1-0F38683D56A1} > \Device\{DBA2C2F4-E6FA-4BC7-8008-0CC46A3A77DA} > > I moved NdisWanIP to the bottom of the list. Now, NSLOOKUP is defaulting to > my local DNS server as expected. But, "ping mydomain.com" is still > resolving to the public IP. IPCONFIG /FLUSHDNS. Ping domain.com. Still > reaching the public IP. Where is this DNS lookup cached? Grrr, Vista has > too many caches! > > So let's try a hosts entry for mydomain.com. Ping mydomain.com - now > reaches the correct private IP. But "net use m: /home" - still fails. "net > use m: \\servername\share" - still fails. Still cached somewhere? > > I'll have to reboot and start again with only the hosts entry for > mydomain.com as the workaround, and see what the results are. More when I > know more. Thanks everybody for your comments. > > Carl Excellent work. I don't have/use Vista, so I can't help much more than I have, but I'm sure someone on the list has more knowledge. I'm assuming, for the moment, that the internal servers you're having problems reaching are on the same subnet? I think that's what I'm gathering from your tracert results. Also, I have to question why you have two sets of DNS servers. Why not make static entries in your local DNS for your clients? It's more work up front, but it can be automated, with dnscmd, I think. Kurt ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
