Like tons of other people we’ve had to spin up our VPN solution quickly. Normally when users are in our office they would be considered in the “Trust” zone and since all of that network is behind the firewall, none of it would pass through it.
Now with all of our users on VPN, we’ve put that network into its own zone, but we’re finding that many requests are being denied due to non-standard ports not being allowed because of the “application-default” setting and are creating tons of one-off rules for these.
Anyone else running into this and how are you handling it? Did you stick your VPN network into your Trusted? Are you allowing “all” ports rather than application default? Are you creating individual rules like we are?
We segregate all of our client to server traffic anyway. The GlobalProtect VPN clients land in a different security zone to clients in the offices, but all of our client rules apply to both of these zones.
I think your second question is unrelated to GP, it’s more of a general question about security policy, you just have encountered it because that traffic wasn’t previously going through your PAN. Might respond further on that later, but have too much work to do atm.
I also have separate rules for this zone toward our datacenter zone, DMZ, etc. vs. using the same policies as our campus network.
The reason for this is that I’m also using the PA HIP on the GlobalProtect policies to ensure that a VPN connected endpoint complies with anti-virus patching requirements and is an actual organization asset.
I broke them out because I didn’t want to apply PA HIP to my campus policies just yet.
Same zone/policies as the wifi or wired computers inside the office. Rationale is that in both 3 cases, only corporate computers (with cert from our pki and managed by our IT department) are allowed to connect.
IMO, having different policies for the users depending on where they connect from does not make much sense from a user perspective. In that context, requests to open more things from the VPN will inevitably come and pile on as time goes on, and from there, either:
you accept, everyone just wasted their time (them requesting, you managing your spaghetti policies set) and the security you intended to enforce is no more
you refuse and people will complain because they can’t work (wasting their time as well), and will possibly ending up trying to work around the restrictions with some shadow IT - in turn, time wasted for you hunting these
The moment you start to implement one-off rules you have to question your model: what are the general ideas we are trying to implement in terms of security? How is the lifecycle of those rules managed (lifecycle includes audit and deletion)?
Okay but… back to the basic question… Why are your applications running on non-default ports? We all know we as firewall admins often get to solve things going wrong on dev/sysadmin side, but you may want to shuve the matter back to them.
When I set it up at a previous job I had a dedicated zone for VPN users (helps with policies and during troubleshooting). In my current role I inherited VPN users part of ‘trust’ and it’s not been too bad.
Ok, so There’s a few things. One always use a separate zone, I actually have two depending on where the vpn user is trying to get to (users have a separate account to get to the more privileged network)
Any case your problem isn’t using a different zone.
Your running into a std problem I’ve dealt with. Where your using app-aware rules. I’d actually suggest you use tcp/services etc instead. ie. For my setup I have one rule for my DNS/AD servers so users can get to them. Another so they can access file servers. and another for HTTPs to certain sites. This is for one set of AD users. Most others are actually only allowed to VPN in and connect directly to their desktops via RDP or to a terminal server. Then from there they can do whatever they normally could at their desk.