Is it a default gateway issue? ISA 2004 can force you to use the
default gateway on the remote side.
Also, is it a DNS issue? When you connect to a VPN, even one that
forces default gateway behavior, the DNS order might be wrong.
Apparently it's a 50/50 issue which DNS server will reply first.
I have this problem on my own side, my internal servers have 'corp.com'
DNS settings that resolve to 192.168.x.x. numbers, but when you connect
to the VPN, you get a 66.150.x.x number - outside the firewall, even
though you are on the VPN. If this is the problem, maybe your DNS gets
confused and your local DC suddenly gets reached via a public IP, which
is blocked.
I assume the subnets are separate, i.e. you aren't both using
192.168.0.X.
== John ==
From: Carl Houseman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 12:30 PM
To: NT System Admin Issues
Subject: RE: Lose access to local domain servers when connected w/VPN to
remote / different Windows domain
No, the usernames and passwords are different, and they must remain that
way.
Carl
From: Steve Ens [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 2:35 PM
To: NT System Admin Issues
Subject: Re: Lose access to local domain servers when connected w/VPN to
remote / different Windows domain
You do have a local account on the remote server....same username and
password I presume?
On Wed, Dec 10, 2008 at 1:28 PM, 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/> ~
