Active Directory management tasks slow over SSLVPN?
I have fairly fast & robust internet connections at both ends and most normal tasks behave fine over SSLVPN. However when I need to perform AD management tasks, (modify AD U&C or AD GPO) those seem to crawl for some reason- I haven't actually timed it, but it probably takes a full 90 seconds to open ADU&C. The DC's that I'm working on are right at the other end of the SSLVPN tunnel so I wouldn't expect these tools to behave so slowly.
However, one additional aspect of the AD structure as a whole is that the Global Catalog server is an additional hop away through a BOVPN. I'm not sure that this is a factor because when I'm actually in the office (at the other end of my current SSLVPN, still a BOVPN hop away from the GC server) these AD tools behave fine.
Does anyone else notice the same slow behavior when locally using AD specific tools over an SSLVPN or is it just my setup?
SSLVPN client 12.5.2 & XTM 270 w/ 12.5.2 OS all traffic forced through the SSLVPN
Answers
One other detail for information: while on the SSLVPN, I can RD into any machine at the other end of the SSLVPN and run the AD management tools there and they also run normally.
And for the record I just timed opening ADU&C and it actually took nearly 6 minutes to appear! much worse than my earlier guess.
If this also happens with any other client VPN type, then it may well be a MTU issue.
A resolution is to enable PMTU (path MTU) discovery in the Windows registry.
Also, one can enable black hole router discovery in the registry too.
I have done this in my PC.
Here are the registry keys & values to do both:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
EnablePMTUDiscovery dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
EnablePMTUBHDetect dword:00000000
Hi, just checking in to see if anyone has a different solution for this problem. I recently had to change my SSLVPN to route all traffic through the VPN (we were previously split tunneling). With that I had to create a policy to allow SSLVPN Users access to all trusted and optional networks. However, like Steve, AD U&C now takes 6 minutes or more to open and once open are very slow at opening user properties. Prior to the change, performance was only slightly slower than being in the office on the LAN. I did try the registry changes mentioned by Bruce and also changed the setup to use UDP and AES-GCM encryption rather than AES 256. Nothing changed with the performance of AD U&C. Other connections seem to perform fine - RD, Mapped Drives, etc.
My guess is that the DNS you have on the SSLVPN is not a LAN DNS server set first. Look at the SSLVPN settings on the Advanced tab and put in the AD domain name and an AD DNS server IP address.
Gregg Hill
In my case, the SSLVPN DNS servers are LAN (AD) DNS servers and additionally also the AD DC that is being used to administer AD Users & Computers.
My situation is full tunnel. I've never tried it with split tunnel setup
Thanks for the replies. Steve, sounds like my situation is the same as yours - I also have local DCs serving as DNS servers specified in the SSLVPN setup and have FQDN in the domain name. Is your problem resolved or still going on?
The problem It is still continuing. However, I typically don't do all that much AD management (ADUC or GPO) while on the SSLVPN, so it's not that high on my radar. I just launch the AD management tool and move on to something else and hope that I remember what I was going to do when it's actually ready for use
. If I really need to do something quickly for a specific purpose I'll switch to the IKEv2 vpn which works fine.
Anyone ever figure out a solution to Steve's issue. We are facing a similar issue. Local DC serving as the primary DNS server for the SSLVPN setup.