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?
Solved! Go to Solution.
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).
Can't this be done just the way you describe with a normal Security Policy?
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.
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.
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.
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 Live Community as a whole!
The Live Community thanks you for your participation!