Crowdstrike and host-based firewall and Global Protect (resolved)

[NeonNetSec]

Hey all,
We are working on a large-scale deployment of Palo Alto Global Protect VPN client in a relatively standard Global Protect build/architecture. We do use DNS load-balancing for 2 Portals in different parts of the US, but we have done quite a bit of testing with that all disabled and this issue is clearly unrelated to that.

The managed workstations we are trying to deploy Global Protect VPN client on have Crowdstrike on them working with the Windows host-based firewall. Our Crowdstrike policy set is written with a bunch of explicit allows, and implicit denies. 

We are experiencing this intermittent, sporadic issue where sometimes, most commonly after fresh boots/reboots, the Crowdstrike firewall seems to just ignore all of the explicit allow rules related to Global Protect and deny the traffic. We can see in various different logs that traffic to the Portals and Gateways gets denied by the Default Deny policy in Crowdstrike. The result is that the Global Protect client fails to establish 443 and ipsec tunnel traffic to the gateways, since it's blocked. Interestingly enough, other services/apps are unaffected. F5 Big-IP VPN client for example never has this issue in the exact same environment.

Obviously based on all of this it's not really a Global Protect issue persay, but this is just an SoS..

Has anyone experienced this issue?
Does anyone currently have a Global Protect deployment on managed Windows workstations with Crowdstrike installed? Additionally, do you have a Default Deny policy?
Any outside-of-the-box thoughts? Thanks!

EDIT: posted this on other sites as well and got some input/feedback so adding some more information here:

1. in this configuration we tunnel ALL traffic through Global Protect Gateway (NO split tunnel), however the failure happens before the workstations and clients can even establish the IPsec tunnel to the Gateway.. 
2. we do not use Enforce GP for Network Access
3. this is an on-demand (manual) Global Protect configuration

EDIT 2:
Looks like we've got a resolution to this issue. 
Since this is a Palo Alto forum I will keep the technical details related to Crowdstrike light - 
Resolution: issue is not Global Protect / Palo in any way, issue seems to be specific to Crowdstrike and the host-based Windows firewall. We modified the Crowdstrike firewall policy to only filter on Destination IPs and Ports and wildcarded out the file path, and traffic works.

Additional info - Crowdstrike looked at logs and confirmed they see an ongoing issue with our host-based firewalls and the Crowdstrike instructions (specifically looks like the xmlfilters are being modified in some way, still researching). 

[JayGolf]

Hi @NeonNetSec ,

I don't have much experience with Crowdstrike, but could you share any recommendations that you come across? This could be helpful for future users coming across similar issues. 

Thanks!

[NeonNetSec]

Yes, looks like we've got a resolution to this issue. 
Since this is a Palo Alto forum I will keep the technical details related to Crowdstrike light - 
Resolution: issue is not Global Protect / Palo in any way, issue seems to be specific to Crowdstrike and the host-based Windows firewall. We modified the Crowdstrike firewall policy to only filter on Destination IPs and Ports and wildcarded out the file path, and traffic works.

Additional info - Crowdstrike looked at logs and confirmed they see an ongoing issue with our host-based firewalls and the Crowdstrike instructions (specifically looks like the xmlfilters are being modified in some way, still researching).