About Gareth-Doyle

I thought it could potentially be a Cloud routing issue, but when I configure HA1 to use management and set eth1/5 as HA1-Backup they all come up green. When I flipped them back to use eth1/5 as HA1 and Management as HA1-Backup, HA1 again went red while HA1-Backup and HA2 were green. Very odd. ... View more

It could be the case as you say but still you can test if the globalprotect options will not terminate the RDP "User Switch Tunnel Rename Timeout" also check if this option is enabled "Enforce GlobalProtect for Network Access" as if the VPN is not up the globalprotect will block any connections till the VPN us up and this caused me a lot of issues in past. Outside of that maybe raise a support case.   https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/globalprotect-quick-configs/captive-portal-and-enforce-globalprotect-for-network-access     Also maybe check the split-tunnel option in the globalprotect configuration as the below article seems to match in some way your issue "Why Does a Local Client Device Break RDP Connection to Cloud-VM Platform when Connecting to a GlobalProtect Gateway?":     https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HAoMCAW&lang=en_US%E2%80%A9     Edit:   It is not mentioned in the link but you can also create split tunnel based on application try to exclude the RDP process:   https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/globalprotect-gateways/split-tunnel-traffic-on-globalprotect-gateways/configure-a-split-tunnel-based-on-the-domain-and-application ... View more

Looks like this was an issue where we didnt have a NAT rule for the client vpn zone. Once I made a client vpn to outside nat that seemed to fix the issue. ... View more

@aleksandar.astardzhiev , thanks for your reply. I should have replied sooner myself.   I was able to resolve this issue with the original solution actually. The issue (i.e. why it was failing initially) was actually due to Chromium based browser engine and not due to the firewall. However Chromium caches connections, possibly reusing tunnels, etc... was permitting access to the main site only AFTER first visiting the permitted URI. ... View more

Latest Updates The signature 81845 has been revised to address the false positive issue and released on 05/03/2022 with the content update 8565. This issue should be resolved if you update to content 8565 or higher.    ... View more