"Use default gateway on remote network" is NOT checked for the VPN TCP/IP
configuration.
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
Then I connected the VPN (with VPN gateway server credentials).
Then I mapped a drive to a remote AD DC (using remote domain credentials).
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?
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.
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
-----Original Message-----
From: Kurt Buff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 11:35 PM
To: NT System Admin Issues
Subject: Re: Lose access to local domain servers when connected w/VPN to
remote / different Windows domain
Start at the beginning...
When this problem occurs, can you ping the hard-to-reach server by IP
address? What does 'ping -a ip.add.re.ss' reveal? If those work, ping
by name, but if those fail, what does tracert reveal? What does
ipconfig /all reveal - as others have voiced, I have my suspicions
about the default gateway being set to the remote network, but first
things first.
Kurt
On Wed, Dec 10, 2008 at 11:28 AM, Carl Houseman <[EMAIL PROTECTED]>
wrote:
> This problem has bothered me a long time, and happens daily. It's so
> bothersome, I'll send some Dale & Thomas popcorn to the first person who
can
> come up with a solution or a tip that quickly (without many hours of
effort
> on my part) leads to a solution. Advice such as "call Microsoft" does not
> qualify for the popcorn!
>
> Past history: The problem was seen for Windows XP but seems to be worse
> under Vista. In fact I wrote about it in reference to XP to this list a
> year or two ago without any resolution. Certainly what I'm doing here
can't
> be that unique, aside from relying on Microsoft-based VPN solutions...
> (kindly withhold comments on the worthiness of those solutions).
>
> Goes like this:
>
> In my local office, there are two 2003 servers - member and domain
> controller. My everyday Vista SP1 is joined to that domain. I have
drives
> mapped to both servers.
>
> I use an L2TP/IPSEC VPN connection to connect to a client's network. The
> client's VPN gateway is ISA 2006, joined to the client's Windows domain,
but
> I authenticate for the purpose of the VPN connection using a local
username
> on the ISA server. We'll call the ISA server "ISAVPN" in further
> discussion.
>
> What happens: Sooner or later I will be unable to access the drives
mapped
> to my local domain's servers (UNC references to those servers also fail).
> The error returned when just trying to do anything at the CMD prompt
> defaulted to a mapped drive on either server is:
>
> Logon failure: unknown user name or bad password.
>
> Once I disconnect from ISAVPN, at the very same CMD prompt, I again and
> immediately have access to files on my local servers.
>
> This seems to affect access to the member server a short time after
> connecting to ISAVPN. Access to files on the domain controller usually
> keeps working much longer, but eventually I lose it as well. This
behavior
> has guaranteed repeatability 100% of the time.
>
> I should note that the domain controller's mapped drive is "available
> offline" but Vista does not switch to offline because of this problem.
>
> Looking in the security event log of the server, I see events 529 and 680
> (source Security), in pairs, related to the login failure, with the 529
> having the most information:
>
> Logon Failure:
> Reason: Unknown user name or bad password
> User Name: local_username_on_ISAVPN
> Domain: ISAVPN
> Logon Type: 3
> Logon Process: NtLmSsp
> Authentication Package: NTLM
> Workstation Name: MYVISTAPC
>
> My take on it: At some point, SMB access has to re-authenticate and is
> using the more recent credentials from the VPN connection to talk to my
> local servers. I'm guessing binding order somewhere is the problem, but
> where can I find and fix this binding order? A permanent one-time
solution
> would be nice, but it's OK if I have to fix it every time after making the
> VPN connection.
> thanks all,
> Carl
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
