About OwenFuller

"Shouldn't GP see that as part of the connection process and stop the connection vs. letting it connect?" Well, if the client can't reach the portal from inside the network, and the client connects from inside the network initially, it's not even going to get the portal config to tell it what the internal host check address is in the first place.  You could also trigger this error if a users switches from an external to internal network (e.g. from mobile hotspot to corporate WiFi), and the client is configured to try to reconnect.  This is also particularly problematic if you're using and "always on" connection method, as the client will attempt to reach the portal anytime.  Rather than getting an error, you want it to connect to the portal to check for config updates, and then not connect to a gateway, at which point the client will say "Connected - Internal" instead of connected to a particular gateway.     It's been awhile since I've done a new portal setup, so I don't recall the exact behavior, but I'm not sure you'll avoid getting the connection error if the portal isn't accessible.  You should be able to experiment a little to determine what works though.  Having setup portals a few different times now, I still suggest making them accessible from your internal network to avoid the most hangups and confusion to users.  If you're not doing desktop SSO to pass the user's credentials to the client when they log into the OS, you can use cookies, and set the portal cookie timeout to a really high time (like a year), and use a much shorter time (like a few hours) on your gateway which is the more important thing to secure since it actually terminates the VPN tunnel.  This will keep users from being prompted to authenticate to the portal when if GP tries to connect while on the corporate network. ... View more

Do you have security policies allowing the Internet traffic from the zone your GP tunnel is in to get to the Internet?  Do you see any blocks in the monitoring tab? If the security policy isn't the issue, and you are trying to exclude traffic from the tunnel and go straight to the internet, adjusting the default gateway isn't the best way to go.  GP generally (at least the ways I've used it), operates in tunnel mode, and clients get an IP address with a 255.255.255.255 subnet mask, and the interface doesn't have a default gateway.  The split tunnel section of your gateway configuration determines what goes down the tunnel, and what doesn't. If you're wanting to exclude certain traffic, you can specify it in the split tunnel exclude section, or alternatively only include certain internal subnets in the split tunnel include section. ... View more

You actually need to allow clients on your internal network to reach the portal, even though they won't initiate a tunnel connection to the gateway.  This will prevent the error, and will also let users log into the portal initially to pull down configs from inside the network if desired.  Try the following: - Create a security policy allowing traffic from your Trust zone to your the public IP/FQDN of your GP portal in your Untrust zone allowing panos-global-protect as the application. - If normally NATing traffic from your Untrust to Trust zone, create a NAT policy which excludes traffic from your Untrust zone to your GP portal from being NATed. - Make sure your DNS server has a PTR record for the IP address you are using in the Internal Host Detection section of the portal config (i.e. you must be able to do nslookup 10.0.0.1 and get gpcheck.domain.local, or whatever internal record you are using). - Under Your Portal > Agent > Your Agent Config > Internal, make sure you check "Internal Host Detection IPv4" and put in the IP address and domain name for the PTR record you are using to determine that the client is on the local network. EDIT:  I actually just considered that you could try connecting externally the first time you connect.  Once the client has the portal config with the proper IP/hostname for the internal host check, it might not error out anymore.  If you want to avoid the hassles though, do as I suggested above. ... View more

Yes, to lock them down the most, put 0.0.0.0/0 in the Include section, nothing in the Exclude section, and check the "No direct access to local network" checkbox.  This will cause all the client's traffic to go down the VPN tunnel.  Whether you do 0.0.0.0/0, or specify the VLAN in the split tunnel config, you're still going to have to make the security policies to allow traffic from your Vendor zone to your Trust zone (assuming you haven't modified your interzone-default rule).  Make sure you check the "Log at Session End" checkbox under Actions > Log Setting in your security policy if you want to record hits in your monitor tab. Let me know if you have any other questions, or mark the issue solved if you get it all working. ... View more

Glad to help!  That gave me fits for a week or two not long ago. "More secure" might be hard to answer, given I don't fully know your environment.  If you want to make sure all their traffic is running through the VPN connection it might make sense.  It would be slightly simpler for future changes.  You'd probably need a security policy for Internet access from the vendor zone if needed, and others for any internal services like DNS.  Then you could created policies for specific users or groups giving them access to whatever specific servers/resources then need on your internal zones. ... View more

We had issues with GP and Jabber about a month ago. It seemed to explicitly affect people using Verizon iOS devices as hotspots. I was able to fix it by disabling the SIP ALG. It’s really simple—literally just a single checkbox. Worth a try. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClEsCAK ... View more

Yes, you can use “any” app with a particular service port instead of a pre-defined app.  Another option is to define a custom application based on the ports used. I would also check the Monitor tab to see how Palo identifies the applications, and adjust your security policies accordingly.  ... View more

Okta auth has been working fine for us all week without reports of errors.  I downloaded the javascript, and it looks like line 1, char 1 is just the start of a comment block, so I'm not sure why it would do this.  It looks like you're on a windows machine.  You might try making sure Internet Explorer is up to date with latest patches, as the GP agent users IE in the background when doing SAML auth with Okta. ... View more

I'm not sure whether this is possible with SAML.  I originally tested some of our GP portals/gateways w/ a RADIUS auth profile.  Once I added a SAML profile above it though, it seemed like it was one or the other (whichever was higher in the list).  You might need to consider two separate portals and gateways   Alternatively, you could do a single portal with LDAP auth that has a very long cookie expiration (e.g. 365 days), and two gateways (one with LDAP as the authentication, and one with SAML) that have much shorter cookie time-outs (e.g. 8 hours).  The LDAP gateway could be set to high priority, and the SAML gateway could be set to manual only in the portal agent config.  If the user is unable to authenticate with LDAP, they could choose the SAML gateway instead. ... View more

@mdensley I'm not sure exactly what you're trying to accomplish.  Could you elaborate? If you don't actually want to enforce GP for network access, I'd disable that option in your portal config.  The "Allow traffic to specified hosts/networks when Enforce GlobalProtect Connection for Network Access and GlobalProtect Connection is not established" is really intended for making limited exceptions when you want to lock down all network access if you user isn't on VPN.  If your main goal is just to notify users when they've lost their VPN connection due to a poor network connection for example, I'd suggest a different approach.  You might want to start with enabling cookies on your portal/gateway which allow the user to reconnect withing a specified amount of time (whatever makes sense with your security/operational requirements) without re-authenticating.  Then, use the "Automatic Restoration of VPN Connection Timeout (min)" and the "Wait Time Between VPN Connection Restore Attempts (sec)" settings to enable GlobalProtect to automatically try to reconnect if it briefly loses connection.  This is seamless to your end user, and requires no prompt or interaction.  If you want the VPN to generally be connected for the user all the time, but not "enforced" for network access, then you can set the "Connect Method" to User-Logon (Always On). ... View more

Interesting.  We're using a cert signed by Digicert for our portal, so I had assumed this wasn't necessary.  I may have to give it a try though.  Thanks. ... View more