Robing66066
asked on
Windows Logon very slow over VPN link
We've set up a site to site VPN link using a 1700 series Cisco router and a 515 PIX firewall. The workstations on the remote end are Windows XP, the main site is running Windows 2003 in native mode.
We're noticing an extremely long logon period for the remote users (takes around 15 minutes). Once in, things move fast enough, but the logon just takes forever.
Any thoughts on what might be causing this and how to fix it?
Thanks in advance...
We're noticing an extremely long logon period for the remote users (takes around 15 minutes). Once in, things move fast enough, but the logon just takes forever.
Any thoughts on what might be causing this and how to fix it?
Thanks in advance...
Eladla
Are you using a windows xp VPN client or are you doing a hardware based VPN?
Often long XP login delays to an Active Directory environment are DNS related. Try pointing the XP clients at the primary domain controler for their DNS (or have the DHCP server give out the IP of the PDC as the DNS to use).
Agree with fixnix, this appears to be a DNS issue. Suggest perhaps putting in a secondary AD DNS server at the remote site.
ASKER
Both the clients at the site list the our two domain controllers as their DNS servers. I was hoping to avoid putting a server in the site as there are only two people there and we have quite a few of these sites to do if we can make this work... Is there any way to confirm the problem is DNS related?
I would setup up the client workstation to allow lmhosts lookup and put the following entry in their lmhosts file...
xxx.xxx.xxx.xxx mydomaincontroller PRE DOM:mydomainname
replacing the x's with your domain controllers ip address... the mydomaincontroller with your domain controllers netbios/wins name (not FQDN).... the mydomainname with your domain names netbios/wins name (not FQDN)... and reboot the machines... attempt to login... if it works then it's a DNS issue... usually the long logon times are caused by the workstations having trouble locating the srv records for the domain controller...
xxx.xxx.xxx.xxx mydomaincontroller PRE DOM:mydomainname
replacing the x's with your domain controllers ip address... the mydomaincontroller with your domain controllers netbios/wins name (not FQDN).... the mydomainname with your domain names netbios/wins name (not FQDN)... and reboot the machines... attempt to login... if it works then it's a DNS issue... usually the long logon times are caused by the workstations having trouble locating the srv records for the domain controller...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Still looking at this one. Will get back to it soon.
ASKER
That seems to have done the trick. Thanks.
ASKER
As it turned out, that helped, but didn't solve the whole thing.
The final answer turned out to be a problem with the maximum MTU size of the ISP who provided the VPN connection. The max size was lower than the size of an authentication packet as sent from the workstation/server. The packet ended up getting fragmented and the server rejected it, sending back a packet with the "Don't fragment" bit turned on. Unfortunately, the workstation wasn't set up to respond to the "don't fragment" request, so it kept sending without adjusting the MTU.
We had to do a reghack via GPO to every server/workstation to get it to work. Took several hours with Microsoft to find and resolve. Very nasty little problem.
The final answer turned out to be a problem with the maximum MTU size of the ISP who provided the VPN connection. The max size was lower than the size of an authentication packet as sent from the workstation/server. The packet ended up getting fragmented and the server rejected it, sending back a packet with the "Don't fragment" bit turned on. Unfortunately, the workstation wasn't set up to respond to the "don't fragment" request, so it kept sending without adjusting the MTU.
We had to do a reghack via GPO to every server/workstation to get it to work. Took several hours with Microsoft to find and resolve. Very nasty little problem.