Allow traffic to specified hosts/networks when Enforce GlobalProtect for Network Access Enabled

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Allow traffic to specified hosts/networks when Enforce GlobalProtect for Network Access Enabled

L4 Transporter

We've been troubleshooting some issues encountered when using the "Enforce GlobalProtect Connection for Network Access" option in our portal agent configuration.  Our TAC engineer mentioned that he had seen a setting called "Allow traffic to specified hosts/networks when Enforce GlobalProtect Connection for Network Access is enabled and GlobalProtect Connection is not established" in 8.1, but didn't see it in 9.0.  (The setting should allow certain hosts to be exempted from the enforced use of GP.)  However, today I noticed it in the portal config for the first time (we just updated to 9.0.4 last week).  I tried putting in an IP address for the parameter value, and also using the whole subnet w/ mask.  However, it didn't work to allow access to those hosts.

I can't seem to find documentation for this parameter anywhere!  I've looked in the offline help in Panorama, v 8.1 and v 9.0 GlobalProtect administrator's guide, searching on this forum, and searching Google in general.  The TAC engineer didn't even have documentation for this.  Does anyone know the syntax, or how to get it to work?

22 REPLIES 22

L4 Transporter

I tried using 0.0.0.0/0 to see if I could just get the notification when disconnected but not block user traffic, but it was still blocked. any idea's?

0.0.0.0/0 is too large and it is the opposite of GP enforcement. I would expect that 0.0.0.0/0 is ignored. Can you try with a smaller subnet?

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

Thanks, Yea we've done that and the situation improved. But we are still seeing occasional P-Access disconnects forcing the user to manually reconnect. Our connect method isn't user-login, but intended to be on-demand. The essential goal is to keep the tunnel up until the user disconnects. if the tunnel drops and doesn't return within 90s, we want to notify the user the tunnel is down. We display the icon on toolbar, but thats not enough notification. If this isn't possible with GP today, I'll submit a feature request.

I think the closest you will get is doing the cookies with the auto-reconnect option. I believe this should still work just fine. It’s not going to do quite what you want in terms of a specific message, but it should still pop up the GP window from the system tray as it tries to reestablish the connection. Beyond that, you might be right to go the feature request route. 

If you fill in the FQDN area and then delete the value, the firewall will complain too.   Seems like either one of these fields, once completed, is enough to make you have to trash your Agent config for that entry, or force you to enter a value in it.   This should be fixed.

This issue is still with GP Agent 5.1.x

L0 Member

The issue (error when reverting back to empty value) still exists in GP app version 5.2.8-23.

  • 17772 Views
  • 22 replies
  • 0 Likes
  • 101 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!