Active Directory Users & Computers slow over GlobalProtect

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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,

29 REPLIES 29

"dsa.msc /server=" is the best option. The weakhostsend either enabled or disabled is useless. This was not an issue prior to the upgrade to 5.2 so they changed something and need to address it.

Is there any new information about this? We're on 5.2.4 and we still have this issue.

L0 Member

We had the same problem, and based on what we read here in this thread, we just disabled IPv6 on the virtual network adapter for GlobalProtect, and it resolved the issue.  We are two for two with this solution so far.  If all else fails, just disable IPv6 on all your network adapters...assuming that you do not use IPv6, of course.

L1 Bithead

We experienced this issue as well on GP 5.2.7, PanOS 9.1.10.

 

The registry command doesn't work because it won't run as admin without "start-process powershell -Verb RunAs", which still pops UAC prompt as expected.

 

Running the command manually didn't work for us either.

 

Found that running "Set-NetIPInterface -WeakHostSend Disabled" and "Set-NetIPInterface -WeakHostReceive Disabled" fixed the issue. Determined these commands worked because it disabled weak host send and receive for IPv6 as well as IPv4.

 

Disabling IPv6 on LAN and WiFi adapters fixed the issue.

This is something that palo should address.   I've tried the split tunnel and the resolution still doesn't work for us.   Only thing that works is disabling IPv6, which is unacceptable in todays age.

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!