When you isolate an endpoint, you halt all endpoint network access — except for traffic to Cortex XDR. This can prevent a compromised endpoint from communicating with other endpoints, which reduces an attacker’s mobility. After the Cortex XDR agent receives the instruction to isolate the endpoint and carries out the action, the Cortex XDR console shows an isolated check-in status. To ensure an endpoint remains in isolation, agent upgrades are not available for isolated endpoints.
Traffic to Cortex XDR can be halted in some cases. For example, enabling the GlobalProtect feature “Enforce Global Protect for Network Access” will block ALL traffic on GlobalProtect clients until the GlobalProtect agent is internal or connects to an external gateway. Forcing users to connect to GlobalProtect to access the network reduces the security risks of exposing your enterprise to endpoints who aren’t connected via VPN. In this case, to ensure communication to Cortex XDR is always allowed, an IP or FQDN exclusion can be made for the XDR cloud. As best practice, it is recommended to create FQDN exclusions because domain names do not change as often as IP addresses do
The IP address and FQDN names used by the XDR service can be found on Resources Required to Enable Access to Cortex XDR; find out more about the enforce option in the resources list at the bottom of this article.
Still, if the FQDN exclusions are configured, then the process (the native operational system DNS process or custom agent specific process) that the VPN agent uses for the DNS resolution should also not be isolated by the XDR system as when the VPN agent can’t resolve a DNS/FQDN domain name then it can not be excluded and this is where ” Network isolation allow list ” comes into play.
A quick note is that with DNS FQDN exclusions better to use the Palo Alto DNS Proxy feature where your clients will use the Palo Alto as local DNS resolver as it is possible that the client's DNS to resolve differently the FQDN name than the Firewall as inteligent DNS services can do this.
This feature is located under the “Agent Settings Profile” and allows a process and destination IP address to not be blocked during isolation and for an IP address also a wildcard can be configured. Sometimes a process may use another process for DNS resolution, so it should be checked which is the final process that does the DNS resolution for the VPN agent.
If you need to isolate an endpoint but want to allow access for a specific application, add the process to the
Network Isolation Allow List . The following are considerations to the allow list:
This is a really helpfull XDR feature as many other EDR and Endpoint Security solutions when isolating the device can't exclude the VPN agent DNS resolution and this becomes a big issue. Some EDR and Endpoint Security solutions can only exclude from isolation other applications and VPN agents that are from the same vendor and this is vendor lockdown.
Just for an info I have seen this issue with another VPN agent and their feature that is like “Enforce Global Protect for Network Access” as there is a big chance that Globalprotect may use the same DNS process as the XDR agent (XDR is not going to block their own DNS resolution) or the XDR knowing that the Globalprotect DNS resolution shouldn't be blocked but I used Globalprotect as an example as in this forum I want to talk about Palo Alto stuff 🙂
*For the GlobalProtect split-tunnel, there is an exclusion that is based on process and this may at some point be added also for the Enforce option and then it will be much easier to just exclude the XDR process that connects to the XDR cloud console. I have seen the process exclusion option for "Enforce Global Protect for Network Access” in the Globalprotect PanGPS/PanGPA agent logs, so it should be added to some point.