- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
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,
12-02-2019 02:16 PM
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}"
12-03-2019 08:49 AM
Hmm I don't seem to have a key for post-vpn-connect under settings just "remove-gpa-cp"
12-03-2019 09:23 AM
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!
03-25-2020 06:55 AM
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.
03-25-2020 07:02 AM - edited 03-25-2020 07:04 AM
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.
03-25-2020 01:47 PM
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
04-22-2020 12:41 PM
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
07-02-2020 08:09 AM
That worked for me. Thank you
07-07-2020 08:35 AM
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}
07-27-2020 01:15 AM
Hi @scott.chaput ,
By IP scopes of Globalprotect IPs you mean the fqdn address of portal/gateway?
Thank you!
07-27-2020 01:53 AM
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
08-17-2020 03:53 AM
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.
08-17-2020 02:27 PM
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.
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!