Seperate policy for IPSec VPN and SSL VPN?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Seperate policy for IPSec VPN and SSL VPN?

L1 Bithead

So I would like to have different policies based upon what device a user comes in from. If they use Globalprotect with HIP checking, they are given a less restrictive policy. Where as if they come from an iphone with ipsec, they are given a more restrictive policy. Both ipsec and SSL are hitting the same GP gateway. I see no way to differentiate the sessions other then creating a new gateway for logical segmentation and only alow SSL on one GW and only allow IPSec on the other. I would like to maintain the single gateway if possible. Anyone have any suggestions?

1 accepted solution

Accepted Solutions

Can you use 2 different Loopback interfaces and IP addresses and create 2 zones (IPSEC and SSL) then differentiate rules based on zones?

Steve Krall

View solution in original post

7 REPLIES 7

L6 Presenter

Setting up a new VSYS should do this as you already explained (one who only accepts IPSEC the other only accepts SSL).

Otherwise, cant you in the hipsprofile define which device the client is using?

Or cannot one use different zones, one zone for ipsecclients and one for sslclients?

Another method would be if you place the hardware devices in different AD-groups and by that create policies (only allow AD_IPSEC and not AD_SSL and the other way around per security policy).

Hi there,

Can't this be done just the way you describe with a normal Security Policy?

  • One policy rule checks for HIP state... if a client matches then this rule allows less restricted access
  • A following policy rule only allows more restricted access.  All other users/devices that did not send HIP information will match this more restrictive rule.

Cheers,

Kelly

Dunno if that might work... keep in mind that PA is like most firewalls top-down first-match (only ACL's which doesnt do that, which I have found so far, is the ipf/pf from *BSD and the ACL engine in Allied Telesyn equipment (I think AT changed into Cisco-style in their latest hardware releases but there are still a few AT devices which isnt the latest models still out there).

But sure if your SSL clients wont hit the rule containing hipprofile then they will hopefully hit the following rule without the hipprofile.

The problem here is what to do with your IPSEC clients (iphones etc) that should hit the hipprofile but for some reason fails the hip control?

The Iphones will never hit the HIP rule since there is no native Global Protect client for them today.  They will automatically get the more restrictive rule that does not contain the HIP match criteria.

Cheers,

Kelly

Indeed that is the problem. How do you differentiate the GP SSL client that fails HIP check, with the IPSec client? From what I know, there is no way for an IPSec client to pass a HIP check or policy match rule. 

Can you use 2 different Loopback interfaces and IP addresses and create 2 zones (IPSEC and SSL) then differentiate rules based on zones?

Steve Krall

Works great as skrall mentioned. Create another GP interface for the Windows/MAC based GP clients. If you have spare public IP's add them as /32 loopback interfaces and use them in the second GP config.

  • 1 accepted solution
  • 4601 Views
  • 7 replies
  • 0 Likes
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!