Active Directory Users & Computers slow over GlobalProtect

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Active Directory Users & Computers slow over GlobalProtect

L1 Bithead

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,

30 REPLIES 30

L2 Linker

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}"

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

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!

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.

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.

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

 

 

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

That worked for me. Thank you

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}

 

Hi @scott.chaput ,

 

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

 

Thank you!

L4 Transporter

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

Best Regards
Chacko

L0 Member

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.

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.

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

  • 39866 Views
  • 30 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!