Windows365 and GlobalProtect.

[Gareth-Doyle]

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.

Thanks!

[nikoolayy1]

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...

-------------------

• Specify whether remote desktop connections are permitted over existing VPN tunnels by specifying the

  User Switch Tunnel Rename Timeout. When a new user connects to a Windows machine using Remote Desktop Protocol (RDP), the gateway reassigns the VPN tunnel to the new user. The gateway can then enforce security policies on the new user.

  Allowing remote desktop connections over VPN tunnels can be useful in situations where an IT administrator needs to access a remote end-user system using RDP.

  By default, the

  User Switch Tunnel Rename Timeoutvalue is set to 0, meaning the GlobalProtect gateway terminates the connection if a new user authenticates over the VPN tunnel. To modify this behavior, configure a timeout value from 1 to 600 seconds. If the new user does not log in to the gateway before the timeout value expires, the GlobalProtect gateway terminates the VPN tunnel assigned to the first user.

  Changing the

  User Switch Tunnel Rename Timeoutvalue only affects the RDP tunnel and does not rename a pre-logon tunnel when configured.
• To enable GlobalProtect to preserve the existing VPN tunnel after users log out of their endpoint, specify a

  Preserve Tunnel on User Logoff Timeoutvalue (range is 0 to 600 seconds; default is 0 seconds). If you accept the default value of

  0, GlobalProtect does not preserve the tunnel following user logout.

  This option requires Content Release version released on July 8th, 2019 or later.

  Consider the following GlobalProtect connection behaviors when you configure GlobalProtect to preserve the VPN tunnel:

  • If the same user logs out and then logs back in to an endpoint within the specified timeout period in either Always On or On-Demand mode, GlobalProtect remains connected without requiring any user interaction (including portal and gateway authentication). If the user does not log back in within the specified timeout period, the tunnel disconnects and he or she must reestablish the GlobalProtect connection.
  • If a user logs out of an endpoint and then a different user logs in to the same endpoint in either Always On or On-Demand mode, the existing tunnel is renamed for the new user only if the new user authenticates to GlobalProtect successfully within the specified timeout period. If the new user does not log in and authenticate successfully within the specified timeout period, the existing tunnel disconnects and a new GlobalProtect connection must be established. If the new user is in Always On mode, GlobalProtect attempts to establish a new connection automatically. If the new user is in On-Demand mode, he or she must establish a new GlobalProtect connection manually.

[Gareth-Doyle]

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.

[nikoolayy1]

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...

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%A...

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/spli...