Active Directory Users & Computers slow over GlobalProtect

[ShippG]

We are experience an issue that I am curious if anyone else has encountered. When any of us IT folk are VPN'd in via GlobalProtect (tested on different internet connections, hardwired and wifi) whenever we open up MSFT Management Console Active Directories Users & Computers, it takes about 5-7 minutes to open.  I can see the traffic in our traffic logs on the Palo, nothing denied, it just takes a long time until it opens and runs painfully slow once opened. 

If anyone has encountered this before if you could point me in the right direction that would be great, I will update if I do find anything.

Thanks,

[dpeterson4]

Hello,

We ran into this same issue.  We had to add a special registry key.  Problem is cause by weakhostsend in windows or some cases it was a DNS issue.

We had to add the following registry key.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\Settings\post-vpn-connect

Name: command

Data: powershell -Command "Get-WmiObject win32_networkadapter | where-object NetConnectionStatus -eq 2 | where-object ServiceName -ne PanGpd | ForEach {netsh interface ipv4 set interface $_.InterfaceIndex weakhostsend=disabled}"

[ShippG]

Hmm I don't seem to have a key for post-vpn-connect under settings just "remove-gpa-cp"

[ShippG]

Nevermind I figured out how to add this (sorry I'm a network guy my brain is wired differently). Thanks for the input but this did not seem to resolve my issue - back to digging!

[cezarb]

Any new leads on this? I think we might have hit the same issues (probably related to DNS) and the register change did not help either.

[googol]

we also have had this problem too for ages, somehow seems to have resolved itself. We ended up having to give our Helpdesk VDI systems so they could run Active Directory no problems for supporting the users remotely when oncall since couldn't over VPN. Now that we are all remote these days, glad it resolved itself.

we debugged this for days with PAN TAC support, no dice. multiple packet captures, wiresharks, you name it

we debugged this with Microsoft support, they said its Palo Alto. We captured packets from the domain controllers and the client and the firewalls..

definitely was related to DNS at times and related to how they do their interfaces it seemed. We also were seeing traffic going out the wrong interfaces, thanks to Microsoft and their dual network send out packets, DNS was seen going both ways.

Really wish I knew what resolved itself, so I could share.

we are updated to v1903 of Windows 10, not sure if that changed anything, also running newer GlobalProtect v5.0.8 now, so those two changes we did since we last really debugged. We were on 4.1.x previously and Win10 v1709.

[cezarb]

It looks like a carbon copy of our issue and troubleshooting efforts. Thank you for the Windows version tip.

Bug ID GPC-7496 related to this seems to have been fixed in 4.1.11 but probably reintroduced in 5.1.X

[scott.chaput]

We had the same issue, with ADUC and a couple other apps we had.  We dug into our DNS, and found we did not have a reverse lookup for the IP scopes of GlobalProtect IPs.  Once we added those and they started to populate, it was better.  It is still not as fast as being in the LAN, but it is usable now.  Takes 1-2 mins for it to come up, and is pretty responsive after that.  Thought I would share!

BTW we are using Win10 with a mix of 1803 and 1903 (that is a long story), with GP 5.0.5

[USPLATINUM]

That worked for me. Thank you

[AdrianWallis]

The registry key addition doesn't seem to make any difference on 5.1.4

Running the command manually when required does work:

Get-WmiObject win32_networkadapter | where-object NetConnectionStatus -eq 2 | where-object ServiceName -ne PanGpd | ForEach {netsh interface ipv4 set interface $_.InterfaceIndex weakhostsend=disabled}

[Carracido]

Hi @scott.chaput ,

By IP scopes of Globalprotect IPs you mean the fqdn address of portal/gateway?

Thank you!

[Chacko42]

Please collect a wireshark capture on the globalprotect host, while opening the MMC and have a look at everything DNS related.

Win-10 will try to prefer IPv6 over IPv4, so if the router in your home office is IPv6 ready, your client got a IPv6 address and will primary perform communication and DNS over this link, bypassing the VPN.

If the DNS queries look unsuspicious, look at "llmnr" - this is also a IPv6 default mechanism with Win-10 to do name resolution.

Please share your findings here

[YuraZaicev]

We found that 5.0.9 worked better (under a min), when we tried 5.1.4, 5.1.5 or 5.2.0, they all introduced the extra long delay for the RAST tools (up to 10min, sometimes longer).

We have tried to prioritise IPv4 over IPv6 using this command: 

REG.EXE ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0x20 /f

However this did not help, we then tried the weakhostsend suggestion using this command:

REG.EXE ADD HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\Settings /v post-vpn-connect /t STRING /d "powershell -Command 'Get-WmiObject win32_networkadapter | where-object NetConnectionStatus -eq 2 | where-object ServiceName -ne PanGpd | ForEach {netsh interface ipv4 set interface $_.InterfaceIndex weakhostsend=disabled}'" /f

And this had little impact, down to around 5min from 10min but still not in seconds.

We have an open ticket and have submitted PCAP files so lets see what comes of it.

[dougwickle]

Running the following command instantly resolved the issue for 5.2.0 on build 1903:

Get-WmiObject win32_networkadapter | where-object NetConnectionStatus -eq 2 | where-object ServiceName -ne PanGpd | ForEach {netsh interface ipv4 set interface $_.InterfaceIndex weakhostsend=disabled}

I've added the reg key but I have not tested it yet.

Looks like there maybe a more permanent solution specifically from this KB article:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008UNoCAM

I'm not sure how this will impact mixed client environments though.

[YuraZaicev]

Tried that command on 2004 Windows 10 build with no improvement, if anything it made it worse!