Mobile Access Unified Policy with Endpoint VPN clients

[jberg712]

Hi,

As we are attempting to move away from the Legacy VPN policy to using the Unified Policy, we noticed some differences in behavior between the SNX Mobile Web Access and the Endpoint VPN clients.  I'd like to know if this is normal.

For instance, we built our Mobile Access rule as an inline policy.  We are following the admin guide recommendations

1.  Our Base Rule starts with Source -> Access Role that contains only the Mobile Access clients | Dest Any | VPN RemoteAccess Community | Services Any | Action Inline Layer

1.1 Our next layer (.1) has Source -> Access Role User Group | Dest Any | VPN RemoteAccess Community | Service -> "Mobile Access Application - Company Remote Access" | Accept

The Mobile Access Application is one that we have used in the Legacy Policy that allows traffic internally and externally routed through the gateway.  

So the behavior with this setup is this.... Users accessing the VPN on the web with the SNX hit this rule with no problem and traffic is allowed like it should... HOWEVER, the users using Endpoint VPN, all traffic is being blocked.  The logs even indicate that the Endpoint VPN users are hitting the cleanup rule in the inline layer.

To test further I created another inline rule.  The same as the rule 1.1 above, but the Service I left as "Any".  Endpoint traffic is routing and flowing normally.  I can see that Endpoint VPN's hit rule 1.2 (the one without the Mobile Application specified in the service).  

So my question is this.  When it comes to the Unified Access policy, is this normal or the correct design for Endpoint VPN?  The reason asking this is because when we were using Legacy Policy in SmartDashboard, Endpoint and SNX Users in our Corporate VPN group would hit the rule for the Mobile Application and traffic would work without a problem.  So I'm curious as to why Endpoint VPN traffic would not hit the rule with the Mobile Application in the Unified policy, but would when it was a Legacy Policy?

JB

[the_rock]

I remember you posted something similar recently about layering : - ). Anyway, definitely valid concerns. Hey, any way you can attach some screenshots of how this is configured and rules in question? (unless privacy concerns of course).

Andy

[jberg712]

Yes I did and it's finally clicking (to a point).  😃  My screenshot has the rulebase.  You can see I named one rule (14.2) "Remote Access - Mobile Web" (which uses the SNX client and the Native Application "RemoteAccess_ALL").  I then built rule (14.3) because the Endpoint VPN clients would not hit rule (14.2).  The only difference is that the Native Application I had to remove from the Services column. 

BEFORE Unified, Endpoint and SNX would use the RemoteAccess_ALL Native Application rule in the legacy policy for Remote Access to be accessible for both SNX and Endpoint.  Unified isn't behaving this way as Endpoint won't match the Native Application rule

[the_rock]

Ok, so just to make sure Im not misunderstanding this brother : - ). So, please correct me if Im wrong...are you saying now that clients do hit layered rule 14, but then for VPN endpoint client users its dropped? happy to do remote Wednesday if you are free and we can check. Im busy all day tomorrow, so would not have the time, sorry.

Andy

[jberg712]

Yes.  That's correct.  VPN clients hit 14 like they should.  However, VPN Endpoint clients don't hit rule 14.2.  Before I didn't have rule 14.2.  They now hit rule 14.3 which has the "Services and Applications" Cell set to "Any". 

In other words, it's because of 14.3 Endpoint VPN clients work correctly.  Before 14.3, everything on Endpoint VPN all traffic would hit cleanup rule 14.4.

[the_rock]

Ahhh, kk, now I get it. sorry. Im not as smart as most people here, so forgive me if it takes time to figure it out lol

Anyway, what is in services column of rule 14.2? And, also, I assume all users in 14.3 access role would belong in access role of source rule 14.2, correct?

Andy

[jberg712]

The services column of rule 14.2 is a Mobile Application / Native Application you would normally define for Remote Access.  I'm attaching 2 screenshots of it.  

And yes, the users/access role in 14.3 are the same for 14.2

[the_rock]

Ok, here is my personal opinion and I could be totally wrong when I say this (been wrong many times before : ), but strictly going based on logic.

Considering all you did and screenshots you attached, appears that when you have native apps in the rule, that ONLY applies to snx users, NOT vpn endpoint clients, because otherwise, I dont see why when you have service as "any" rule works fine for regular vpn endpoint clients. I bet if you were to disable rule 14.3 and modify rule 14.2 to include something else than native apps, that it would work fine even for vpn users (NOT just snx)

Andy

[jberg712]

That's definitely the behavior that's happening.  I'm trying to understand the difference between what's happening and why between my Endpoint users and the Mobile Web SNX.  In Legacy, they would all hit the same Native Application (or at least that's what I assume is happening with Endpoint users).  If that were true, then why wouldn't Endpoint VPN clients/users hit the same or match to the rule with the same native application in the Unified policy as it did in the legacy?

I'd just like to know if it Endpoint VPN clients with a Unified policy SHOULD be hitting the rule with the Native Application or not as it did when the gateway was still using the Legacy Policy.

[the_rock]

That Im not 100% sure, sorry brother. I will let someone else confirm for you.

[Timothy_Hall · Accepted solution]

The root issue here is that you can only match one rule per overall Access Control layer (including sublayers), and you are using a Unified policy.  When using Legacy you can match one rule in the main Access Control Layer (probably what was allowing your Endpoint VPN users too), and then match the needed application for MAB users in the Legacy MAB layer.  But with Unified you can only match one rule, and Endpoint VPN clients cannot match a MAB application rule as it isn't for them, but MAB users *CAN* match a rule intended for Endpoint VPN users and not get access to the MAB application they were expecting.

The Check Point ATC instructors ran into the same thing when attempting a Unified MAB policy for the new CCSE R81.10 class.  Look at this screenshot:

The original issue was the webapp_* was inaccessible after logging in to the MAB portal.  The fix was to move rule 10 in front of rule 7, because the webapp_* was located on the A-LDAP server and rule 7 was matching the traffic but not allowing access to the needed application object.  Once rule #10 was moved in front of rule #7 it started working, this was originally suspected to be a bug but I believe is expected behavior.  Here is my more detailed explanation for this ATC lab situation:

In just about every rulebase I've seen, as a best practice VPN-related
rules are added just after the Stealth rule and not just in front of the
Cleanup rule. This is because these rules are normally specifying a
specific VPN Community and you don't want rules with the default VPN
Community of Any to be matching VPN traffic inappropriately, as this can
allow undesired traffic to/from the tunnel, and can be confusing when
trying to look at logs matching your VPN rule and not seeing anything
hitting it because the traffic is matching some earlier unexpected rule
instead.

This VPN rule placement worked in the site to site VPN lab, but not in
the MAB lab because of the LDAP rule. Only one rule can match traffic
in a single policy layer. In this case the LDAP rule #7 matched the
http traffic, but the MAB user could not bring up the site. This is
because a MAB user MUST match a MAB application to be able to access
something through the tunnel, full stop. Service http in rule 7 is not
a MAB resource. This is not a problem in legacy mode with MAB in a
separate layer, as in that case LDAP rule 7 would be matched completing
that layer, then the MAB object would get explicitly matched in the
second/next layer thus granting access to the MAB user.

I have not received confirmation that my explanation is plausible from R&D, but I'm pretty sure it is correct.  So I think the takeaway here is that if you are using Unified MAB policies allow all MAB applications first (which Endpoint Security will not match), then have rules matching and allowing Endpoint VPN traffic.

[Daniel_Kavan]

Thanks Tim, this is super helpful.  One not so great thing I've noticed is that I can't use any of my old web and native apps.  I have to create all new ones.  Just wanted to verify that to be the case. 

[the_rock]

There ya go @jberg712 ...the smartest guy in the community @Timothy_Hall to the rescue, as always : - )

[Timothy_Hall]

As it turns out this behavior is partially documented here which might be helpful for future reference:

sk112576: In Unified Policy, when using "Any" in Services & Applications column in Rule Base, not al...

[jberg712]

Thank you Tim and Dwayne.. err... I mean Andy

[the_rock]

@jberg712 ...you can call me Dwayne, all good brother ; - )

Im honored!

Andy