About fjwcash

Ah, there's a Target column in the Policy view page.  By default, it lists "any" which includes all devices in all child device groups to where the policy is created.   In theory, we could create our one-off rules in the GP Device Group, and target them to only the specific Child Device Groups (aka specific firewalls) where it's needed.  As we add those devices to more sites, we add them to the target list.  Eventually (hopefully), that list grows to include all Child Device Groups and it switches over to "any".   Neat.  I think this will actually work.  Was wondering what the Target tab was for, as I couldn't see a reason for targetting rules to only specific child device groups, but now it (mostly) makes sense!   Thanks for the pointer!  I will have to play with this a bit to see if this will do what I want it to do.   And, I think this will actually help to clean up our one firewall that has completely different Security Policies compared to every other site, so it has an (essentially) duplicated ruleset done in the lowest device group (local to the firewall) with a "Deny all" rule to short-circuit the inherited rules from parent device groups. ... View more

Interesting.  Seems like an overly complicated, round-about way compared to making the "enabled" tag override-able.  🙂   Wonder what the Policies tab --> Security Policies --> Post page would look like?  Would you see all the rules as "enabled" and then have to drill down into specific rules to see what it's targeted to?  Or have to use the "Preview Rules" button to see what will actually get pushed to the firewall?   Still think having the enable/disable toggle work in child device groups is a better/cleaner solution.  🙂   (Could also be that our device group hierarchy isn't ideal and there's better ways to arrange things.  We have 1 firewall per child device group.) ... View more

We don't have the logs anymore as we've removed all ECDSA certificates from our GP setup.  The certs don't even exist anymore.  We don't use device certs, these were the certificates used in the gateway configuration.  This was simply changing the self-signed CA root certificate and the certificates used for the gateways (signed by the root CA) to ECDSA.  The portal uses our domain's wildcard cert.   With the ECDSA certificate enabled on the gateway, Windows and MacOS, Android and iOS GP clients were able to connect to the gateway without issues.  Linux clients, regardless of GP client version, would connect to the portal, authenticate the user, connect to the gateway, then error out with something along the lines of "can't authenticate server" when it went to establish the SSL connection to the gateway.  The really interesting part was that manually loading https://gateway.address/whatever-the-pre-flight-URL-is in a web browser on the same Linux station worked.  It was just the GP connection that failed.   Nothing in the gateway configuration on the firewall changed, except which certificate was in use (RSA or ECDSA).  We flipped it back to RSA, and Linux clients could connect without issue.  Flipped it back to ECDSA, Linux clients would not connect.  We even configured 1 gateway with RSA certs and another gateway with ECDSA certs, and would either get a working connection or a failed connection based on which username we logged in with (the username determines which gateway is used).   Tried with GP 5.1.x, 5.2.x, and 5.3.x and the results were the same.  Linux clients could not authenticate the gateway and would not establish a connection if the gateway used ECDSA certificates.   We've since moved back to RSA certificates for everything on our firewalls, and won't be looking into ECDSA anytime in the future.  We have more Linux stations than Windows in our workplace, so we need to make sure the Linux stations connect to GlobalProtect. ... View more

You need to create two separate LDAP Server Profiles (one for each server).   Then you need to create two separate Authentication Profiles (one for each LDAP server).   Then you need to create an Authentication Sequence that lists which order you want to query the LDAP servers.   Then you configure your GlobalProtect setup to use the Authentication Sequence to authenticate clients.   That way, when a client connects to GlobalProtect and puts in their username and password, GlobalProtect will check the LDAP servers in the Authentication Sequence.  If there's a working authentication from the first LDAP server, then the client is connected; if not, the second LDAP server is checked.  If there's a working authentication from that one, then the client is connected; if not, the connection fails.   You have to treat the LDAP servers as separate entities. ... View more