PIX <-> PIX VPN and Windows DC user policies

[flovin]

I have set up a hub and spoke PIX VPN network using IPsec, all IP traffic is allowed to pass through.

At the hub there is a Windows 2003 Small Business Server.

At the remote sites there are only Windows XP clients used by employees working both remotely and at the central office.

Initially I had a problem authenticating to the server, but I found a paper suggesting setting Kerberos to go over TCP instead of UDP and it solved that issue.

Now there is one problem remaining, I can authenticate and access server resources like file shares, I can connect to the Exchange server etc. But the client machines don't get the Group Policies from the server. The error message I get in Windows Event Viewer is Userenv id: 1054 - the Microsoft suggestion is checking if DNS is working, and the DNS works, I can locate the domain controller etc without problems.

I've tried to do LDAP queries against the server, and again it works without problems.

Netbios resolution works fine.

Basically everything seems to work expect getting the Group Policies.

Does anyone have any suggestion where I should look next for the solution to this problem?

regards,

Flóvin Olsen

[sstudsdahl]

Are you able to ping devices on each end of the tunnel? In the article below, Microsoft states that the clients must be able to ping the domain controllers or group policy processing will fail.

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dmebb_gpu_zozl.asp

Steve

[flovin]

Hi Steve,

Yes, I can ping devices on both sides of the tunnel - I tried to have a packet sniffer running to check if I could see any anomaly there, and noticed the pings, they ping each other a few times between other things like dns lookup.

Flóvin

[mostiguy]

There is a registry key to crank up logging on group policy processing. enable it, and check out the system's application event log.

The ideal is to have a DC configured as a GC at each site, otherwise, if the link is down, people could only log on through cached credentials (and thus not log on to machines they have not logged on to before).

Any errors on the DC? ANything about clients not being in a site?

[flovin]

I'll have to search for that registry key.

Yes, I know it would be preferable with a local DC, but circumstances don't allow this.

There's nothing unusual to be seen on the DC at all, there are two sites defined - one being the server local site and the other being the vpn nets.

Thanks for the Policy logging suggestion, I'll have to look into that one.

[henk.janssen]

Hello,

Any progress in this case? Looks like I know a site with the same problem. Curious how you solved it :-)

Thanks

Henk

[henk.janssen]

Hi All,

We upgraded the pix from 6.3.3 to 6.3.4. And all microsoft-policie-problems went away!

regards

Henk

[bfisher666 · Accepted solution]

Here is a vbscript that you need to run on all PC's experiencing the problem.

-------cut below ---------------

Dim wshShell

Set wshShell = WScript.CreateObject("WScript.Shell")

prefix = "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\"

wshShell.regWrite prefix & "GroupPolicyMinTransferRate", 0, "REG_DWORD"

prefix2 = "HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\"

wshShell.regWrite prefix2 & "GroupPolicyMinTransferRate", 0, "REG_DWORD"

msgbox "done"

---------stop cut -----------------

Hope this helps

[flovin]

Yes, this did indeed help, thank you very much for the tip - the problem turns out to be that Windows uses ICMP pings to detect slow links.

First it sends a small ping packet, after the receiving the reply it send a 2048 bytes ICMP ping packet. However the PIX's wont allow ping packets larger than 1394 bytes through, consequently the ping times out, Userenv service believes the server is unreachable, and Group Policy processing stops.

Setting those values to 0 disables detection of slow links and Group Policy is applied.

So Microsoft where right after all, it was a Cisco problem... is anyone at Cisco reading this? Could be an idea to allow larger packets through a VPN if that is possible.

[ehirsel]

On each pix run this command:

fixup protocol icmp error

It is disabled by defualt. I assume that you are running 6.3 code or higher on each pix. See if this helps with your issue. I do not believe that the error messages for ICMP are NAT'ed by default. If this doesn't help then,

With regards to the 2048-byte icmp packets: Is the DF bit set on those frames? Does the 1394 max ping packet include the ip and icmp headers, or just the echo payload? I know that by default, the pix allows a 1380-byte tcp max data payload to account for the IPSec headers; the show sysopt pix command can verify your settings.

Regards, Ed Hirsel

[mnlatif]

To allow ICMP Packets with a payload >992 bytes, you have to disable PIX IDS Signature 2151.

However for a 2048 Byte packet, when sent over an IPSec link will get fragmented and to allow ICMP Fragmented traffic, you have to disable signature 2150.

However the above settings apply globaly to ALL traffic including Non-VPN traffic. So if you plan to do this on the PIX, you should modify the ACL on your Perimeter router to reject fragmented ICMP packets, if that is a security concern for you.

\\ Naman