08-25-2022 10:14 AM - edited 08-25-2022 10:24 AM
We are setting up a Windows365 environment that, obviously, lives in Azure cloud. These machines are access by RDPing into them. Due to some access management controls and the systems not actually living on our network, the Windows365 machines were having issues connecting properly.
One of the engineers on the project got an idea to install GlobalProtect on these machines and connect to our network via VPN, which worked for him after installing the proper certs, etc...
However, he noticed that when he reboots the machine, he is on longer able to RDP into the machine. The only way he is able to get back into the machine is to restore it to a previous state prior to the GlobalProtect installation. He did some testing and noted that after installing GlobalProtect, if he sets the service to start manually, he is able to reboot the machine and then RDP into it, start the GlobalProtect service, and then connect to the VPN.
- Has anyone had any experience with Windows365 and GlobalProtect similar to this issue?
- Does anyone have any ideas on what may be causing the issue, and perhaps, how to correct it?
Definitely a difficult issue as no logs can be pulled due to the machine restoration being needed to even get into the machine.
09-05-2022 07:49 AM
As you are using RDP and globalprotect VPN I think that you are having issues with the user to ip mapping changing as this describes the process https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CleBCAS .
Please see the link https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/globalprotect-portals/defin...
09-06-2022 09:39 AM
Thank you for your response! However, I do not think the related article fits my issue.
The issue is that once GlobalProtect is deployed to the Windows365 build, a reboot of that machine results in the inability for any user to log onto that build. When that build is restored to a "previous version" (i.e. prior to GP having been installed) users can then login to that machine.
09-08-2022 01:38 AM - edited 09-08-2022 03:54 AM
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.
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?":
It is not mentioned in the link but you can also create split tunnel based on application try to exclude the RDP process:
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!