identity information from MUH agent does not propogate to all gateways

[Jonathan]

Hi,

R80.20

Users on PCs and on Termainl Servers sits behind FW1.

Terminal Servers installed with Checkpoint MUH.

FW1 sits behind FW2 which also have IA blade enabled.

Users coming from PCs are correctly identified by both FW (I can see in the log filesthe users under the "Source Username" column).

Users coming from TS are only identified on FW1. In the logs, "Source username" is empty once the packet hits the FW2, and ofcourse firewall rules defined by access_role are not applied.

Is this expected behaviour? Do I need to enable "Get identites from other gatewys" on FW2? If YES, then why is it working with users on PCs?

Thanks

[PhoneBoy]

Are all the gateways involved R80.20?
Is NAT involved at all?

[Jonathan]

Yes, all gateways and management server R80.20

One MGMT server for all gateways.

What do you mean if NAT is involved? In what way?

[PhoneBoy]

Are there NAT rules configured on one gateway that might impact how the other gateway sees it?

[Jonathan]

I don't know of any such NATs. I double checked and didn't see any.

FW2 is the default gateway for FW1

[Jonathan]

Hi @PhoneBoy , 

Any ideas?

[PhoneBoy]

What version of MUH are you using?
Note that I highly recommend upgrading to R80.40, which allows for several improvements in MUH (more users on a terminal server and more traffic types are supported). 

[Jonathan]

I'll check tomorrow the MUH version.

But since the user is correctly identified by FW1, could it still be connected to the MUH itself?

We will upgrade to 80.40 in the future but not right now...

Looks like some configuration issue with the gateways themselves, no?

[PhoneBoy]

The newer versions of MUH operate a bit differently than older versions and sync data incompatible with older gateway versions.
Not sure if that has been backported to earlier releases or not.
I strongly recommend a TAC case here. 

[Jonathan]

Ok, just verifying again: 

'Get identities from other gateways' shouldn't be checked on FW2?

Currently it's not checked, but again, identites from PCs propegate fine to FW2...

[PhoneBoy]

This option definitely needs to be enabled if you’re using any of the agents (MUH or otherwise) since the agent only speaks to one gateway.
You didn’t say how the gateways are acquiring identities otherwise.

[Jonathan]

We only use agents on our terminal servers. Users using their own PCs don't have agents installed.

So maybe I'm making a salad here, but I need to understand the flow here - 

User1 on a PC, sits behind FW1, and want to reach a resource behind FW2.

First point of contact is with FW1, so Identity awareness data is collected there.

request from PC is now routed forward to FW2 since it's the DG of FW1.

Isn't identity data also transfered from FW1 to FW2 or does FW2 aquires it's own Identity data independently from the user's PC?

Also, any negative impact if I enable the 'Get identity data from other gateways' online?

[PhoneBoy]

You still haven't answered the question: how is Identity Awareness to 'acquire' the identity.
If it's AD Query and you've configured both firewalls to acquire them from the same set of AD servers, then both gateways will find out about the same logins done to those servers.
However, this only works for single user hosts. 

For terminal servers, MUH must be used as multiple users are coming from the same IP and MUH helps differentiate between the users.
However, MUH (or any of the agents) can only talk to one gateway.
If the gateway isn't sharing identities, no other gateway will find out about that identity.

So, yes, you have to share identities between gateways to make this work.
It does not add a lot of overhead as it is a demand-driven process. 

As a larger issue, you should configure each firewall to acquire identities from the closest AD server (not necessarily the same ones).
You may also want to move to Identity Collector, which scales better than AD Query.

[Jonathan]

Sorry for that - Yes, it's AD Query and both FW are configured with the same AD server.

Thanks for calrifying things. I'll check that box later on and give an update here if that solved the issue.

[Jonathan]

OK, update - 

I installed latest JHF (take 183) and enabled the 'Get identities from other gateways' on FW2.

('share local identities with other gateways' was always ticked on both gateways.)

However, it doesn't looks like it helped. I still don't see username in logs from FW2, only on FW1.

I have a similar problem from the other way around:

Users are establishing VPN connection (SSLVPN) with FW2, however when trying to access resources behind FW1, their user data isn't propogated.

When I tried to enable 'Get identities from other gateways' on FW1, it broke the IA mechanism, and no user data was available for TS agent AND PCs.

I'm kinda lost here with how this mechanism works...

[PhoneBoy]

Recommend a TAC case here to do further troubleshooting.