R80.40 VSX - Identity Collector and Sharing best practices

[Alex-]

R80.40 Take 77.

I've have 2 VS (let's call them Internal and External) which take identities from the Identity Collector, and it seems to work great.

When I post Intranet links on External thanks to Mobile Access Unified Policy, I configure who has access to what link based on AD group membership.

At this point, results are quite unreliable. Sometimes the link would appear, then at next login it wouldn't.

Checking the logs on Blade:Identity Awareness on External, I see that users are correctly mapped to their respective AD groups.

However, the Mobile Access logs provide "User does not belong to any group" upon login. Then after some time, it works. When the policy is pushed, the issue resets and I need to wait up to one hour, but sometimes more or less (the issue is quite undefined) before the links appear again.

I've tried to use Identity Sharing from Internal (close to AD) to External without much success, there it uses the internal VSX network to communicate between the VS on the ports 15XXX and 28XXX and it's all blocked because of local interface spoofing.

From what I see, I don't really think it's an IA issue because on External, users are consistently mapped to their groups from what I see in the logs, but Mobile Access doesn't seem to capture that or very inconsistently, so I was wondering if there were known scenario similar to this one that some of the community encountered which could provide some advice?

[Tobias_Moritz]

Just my two cents regarding Identity Awareness (cannot say something about Mobile Access or VSX specific stuff):

I heard Check Point recommending using Identity Collector and let it communicate with pdpd on all relevant gateways (which will than provide data to their local pepd for enforcing).

However, if you still want to keep using the old sharing feature where you run pdpd only on one gateways and this pdpd will share its data with the pepd on all other relevant gateways (meaning there is no pdpd on these other gateways), I would recommend making this solution more reliable by following these two SKs:

sk60701 „Alternate IP Address for Identity Awareness communication channel“

--> Allows you to specify the IP address used for IA sharing feature (dst-port tcp/15105 for pdpd -> pepd; dst-port tcp/28581 for pepd -> pdpd). Setting this correctly, you will circument your anti-spoofing issue.

sk63264 - In a Cluster environment, Identity propagation does not occur between an Identity Server (PDP) and Identity Gateway (PEP)

--> Tells you to specify manual NAT rules, to make sure that outgoing IA sharing connections are using the cluster IP address as source address.

We also improved reliabilty for this feature a lot in the past by switching from Smart-Push to Pull. The difference between these two modes is documented in sk149255. There is no hint in this sk, how to change this method for remote sharing, so I will tell you (Maintence Windows needed): guidbedit -> GuiDBedit: Table -> Network Objects -> network_objects -> FirewallWithPEPD -> identity_aware_blade -> publish_method: push. Save Changes and do a policy install on all firewalls you have changed AND on the one pdpd is running on. Be prepared that this change will doom your identity awareness tables, so you have to reset all of them to get a clean start-over (that's why you need a maintenance window). See sk113123 on reason and how to fix this.

[Alex-]

@Tobias_Moritz  Thanks for your input. I tried Identity Sharing as workaround for the Mobile issue but since it seemed to make the whole setup even more complex (I read some of the SK you mentioned) and reading about your experience, I definitely prefer to stick with IC which works well in itself.

Internal and External both report a similar amount of identified users, so I will look further in the Mobile Access blade for that group mapping issue.

[phlrnnr]

You should only switch from Smart-Pull (the default) to Push after working the issue through with TAC.  We too ended up switching to Push, but TAC validated our use case and agreed it made sense.  We were having a lot of issues with identity sharing not working consistently, and Push helped fix that.  But there are other performance implications to consider when switching from Pull to Push.  If having IDA issues after switching, make sure to tell TAC that you are using Push, because they will assume you are using Pull.

[_Val_]

@Peter_Elmer anything you can recommend here?

[PhoneBoy]

You should definitely address the spoofing issue as that’s likely causing at least some of these issues.
Identity Broker may be another way to share the information as well.

[Alex-]

I realize that I have probably brought up two separate issues. There are indeed local spoofing issues from traffic originating from External travelling to Internal but not from Internal to External, because of the way it picked the internal VSX network addresses. I fixed this by adding some NAT rules to ensure traffic from External to Internal is using the real IP and it works. I don't necessarily understand why adding a new VS on a VSX cluster would cause this as I'd expect it to break down the VSX network to avoid overlapping issues like that one.

I wanted to ensure that using Identity Collector on each VS was a better way to go than another form of sharing and it's apparently the case based on documentation and feedback. Which is great as in my first setup, using IC on both machines worked and the identities were there.

The main issue is the behaviour of the MAB. If I create an access role which matches my user and assign it a web application, install the policy, create a login event and then log onto the portal, I wouldn't see the link. The IA Blade would show the login event and associated roles, but the MAB would say "user is not member of any group"., until I wait an undefined period and then it kind of works (link appears but not at each login).

[Alex-]

 Apparently, since upgrade to Take 78, the SSL portal doesn't even load up anymore. Browsing to https://<url>/sslvpn/ provides a connection error, and to https://<IP>/sslvpn/ gives a certificate warning then upon proceeding, the connection is cancelled. FW Monitor shows incoming traffic from my public source to the VS public IP though.

Endpoint VPN works. I will investigate further and open a case if necessary.

[Alex-]

Happy to say that Take 83 did not only fix the SSL portal, but now roles are correctly mapped at each login.