User does not have rsop data at remote location?

We are running into a problem with a remote location that we are joining to a domain that is connected via a Sonicwall VPN. We have another site connected that does not have this issue. When adding to the domain we noticed that it took a very long time and logging in also takes a long time. It seems as though computer GPO is applying fine but user gpo is not. DNS is configured correctly but when running rsop we get 'Invalid Namespace' and when running GPResult we get user does not have RSOP data (this is for any user). When trying to browse to the \\domainname.local we get a username/password prompt. This is happening for all workstations at this site, yet the other site yields perfect RSOP and Gpresult.

These computers were previously part of another domain. Any help would be greatly appreciated. Thanks.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Rob WilliamsCommented:
Make sure the clients, which are likely configured using DHCP from the Sonicwall, receive only your Internal DNS server's IP for their network adapter's DNS configuration. Adding the ISP, even as an alternate/secondary DNS server can cause this problem. If possible, also add the domain suffix to the client machines. This can be done manually (see link) or through DHCP with many routers. With a Window server as a DHCP server it is done as scope option #15.
menreeqAuthor Commented:
It took a while but Ive identified what is going on.  Its a pretty complex issue:

Problem 1:  The Sonicwall VPN is fragmenting the Kerberos UDP packets so the workstation is not able to authenticate successfully with the DC

FIX:  Force Kerberos to only use TCP.  This is a simple registry change on the workstation:

Problem 2:  Workstations use ICMP (ping) packets to check if a DC is alive before it start communicating w/ it.  With the initial ping it also includes a bit more data to test the quality of the connection.  This places the size of the ICMP packet over a threshold and makes the Sonicwall think that it is a ping of death resulting in the packet being dropped.

FIX:  One registry change that is applied to the HKLM and one that is applied to the HKCU  the problem is that this last one has to be applied for every user and that user has to be a local admin while the registry change is applied  definitely doable because we already have everyones credentials but not ideal.

menreeqAuthor Commented:
What I posted above are work-arounds, I was fortunately able to find the root cause - it was the MTU setting on the remote site Sonicwall.  Changed it to 1500 to 1404 - that made everything work.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Rob WilliamsCommented:
Glad to hear you were able to "resolve" menreeq, and thank you for posting your findings.
Cheers !
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.