- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-02-2019 01:51 PM
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,
08-20-2020 05:16 PM
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008UNoCAM
This is happening to users here since moving from 4.1.11 to 5.1.5
Has anyone had any luck fixing this by updating SRV or other DNS records?
I don't want to run a script to fix something that sounds like it may be resolvable by an infrastructure change.
08-21-2020 04:02 AM
We had this issue with several users and the workaround suggested on the article sorted the issue out.
Adding a dummy domain on the split tunnel tab worked. Note: without "no direct access to local netwok" othersie this will nullify the fix of using the domain in split tunnel.
From the admin-guide:
"Disable the No direct access to local network option (Split TunnelAccess Route). If enabled, this setting disables split tunneling on Windows, Linux, and macOS networks."
The 2nd workaround is to disable weakhost mode from the powershell with commands:
Get-WmiObject win32_networkadapter | where-object NetConnectionStatus -eq 2 | where-object ServiceName -ne PanGpd | ForEach {netsh interface ipv4 set interface $_.InterfaceIndex weakhostsend=disabled}
Get-WmiObject win32_networkadapter | where-object NetConnectionStatus -eq 2 | where-object ServiceName -ne PanGpd | ForEach {netsh interface ipv6 set interface $_.InterfaceIndex weakhostsend=disabled}
Both workarounds worked fine for all the users.
Does anyone know if this design is intended to be changed in future GP releases?
I guess this is a something for a feature request. Did someone requested one for this matter?
Thank you!
10-07-2020 05:39 AM
We were running GlobalProtect 5.0.x for a while and just recently upgraded the clients to 5.2.2. And thats when this issue popped up for us. A workaround that I found is to launch ADUC from the command line with the /server switch, "dsa.msc /server=<ip of the dc>". When I specified the ip of the dc, ADUC was very responsive.
10-07-2020 07:02 AM
Hi @DougVanAllen ,
actually for us it was the other way around, upgrading to 5.2.2 fixed the issue with ADUC.
10-27-2020 01:10 PM
What do you mean "add a dummy domain to split tunnel" Do you add a fake domain to the include or exclude? I tried adding the real domain to include, but nothing has improved.
Thanks
Brandon
12-11-2020 10:33 AM
"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.
05-24-2021 02:21 PM
Is there any new information about this? We're on 5.2.4 and we still have this issue.
07-27-2021 01:30 PM
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.
09-01-2021 08:50 AM
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.
10-28-2021 07:24 PM
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.
01-12-2022 04:48 AM
Disable IPv6 to fix this on the WiFi adapter to fix this.
Such as:
https://answers.uillinois.edu/uis/page.php?id=99981
I can't take credit for this fix. Found it on redit
01-19-2022 06:55 AM
Hi,
With GP 5.2 and higher you should not have anymore Problems, see: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008UNoCAM
01-19-2022 06:59 AM
My company is on GP 5.2 and still had AD slowness until disabling IPv6 on the Wifi adapter.
01-19-2022 07:10 AM
Hi @NathanielM ,
as in the other articel is writen, it depends on the DNS Split Tunnel Feature setting. It is not written how it depends, but if you read this article: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HBJ5CAO&lang=en_US%E2%80%A... maybe you find the right Split Tunnel Option. I can not test, but i have a customer with the same problem. I have to test this also with that customer, if he has time.
01-24-2022 09:38 AM
Hello Scott
As we has simlar issue on W10 with GP 5.1 or 5.2 for some users. I read this email about "Dug into our DNS..." Is this setting on Corp DNS server ? or on Firewall. As IP scope is assigned by PANFW. I guess it should be some setting on FW ? Please share your fixed setting if you can.
Thank you
Daniel
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!