So, even easier! Set up an authoritative entry in *their* DNS server for your domain, and point the IP addresses in it the way you want.
Tastes great, less filling! On Fri, Dec 12, 2008 at 9:30 AM, Carl Houseman <[email protected]> wrote: >>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:[email protected]] > 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 <[email protected]> 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/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
