Usage of XFF with Identity Awareness and Identity Agent

[MatthiasHoppe]

We are using Identity Awareness for years and now are on R81.20.We are mainly using the Identity Agent on every workstation and are authenticating vs Active-directory on the Security Gateways.

Recently, we have introduced zScaler Private Access for our remote users. One thing coming with it was that all remote workstations are now using a zScaler App Connector, and that one is hiding all the remote workstations behind one single IP-address. Which of course does not work with IA and Identity Agent, as this needs a one-to-one relationship between IP-address and the user identity.

ZPA has been reconfigured to add X-Forwarded-for HTTP headers towards the Security Gateways, and we have verified that this is indeed done. We took some packet captures on the Security Gateways and managed to see an unencrypted HTTP packet, in which the XFF header is clearly visible.

The Security Gateway was also reconfigured to support XFF headers:
- In the gateways's IA proxy properties, XFF was activated and also the group of "proxies" = zScaler App Connectors was configured.
- The FW-policies Network Layer was reconfigured to support XFF (plus all the other layers of that policy)

Still there is no difference in IP-address assignment is visible in the Gateways Logs, neither is any change visible in any "pdp" or "pep" command on the gateway. Which means that the XFF headers are obviously not honored.

My question: Did anybody successfully start using XFF for Identity Awareness? Maybe there is a part of configuration that we have missed and that is not that clearly documented? Any hints?

[G_W_Albrecht]

sk131792 is known ?

[MatthiasHoppe]

Yes, indeed it is. This sk is part of all the doc and articles that have been used to activate XFF header support. 

[PhoneBoy]

Possible you need to do something along these lines: https://support.checkpoint.com/results/sk/sk163796
Might also need to engage with TAC. 

[MatthiasHoppe]

Thank you for pointing this out. Unfortunately, neither scenario 1 nor scenario 2 applies to our case. We do see the "additional symptoms" of scenario 1, but the Identity Agent is able to connect to the PDP of the Gateway. It is indeed registering the IP-address of the proxy and not the client-IP. But the IA is in the end connected.

In the IA log, I can find

[ 29068 12148]@COV-VuRWFujQnvM[22 Nov 14:03:21] [WinHttpCCC (NAC::IS::TD::Events)] UTILS::WinHttpCCC::send_request: Got (CCCclientRequest
:RequestHeader (
:id (1)
:session_id ()
:type (NACHello)
:protocol_version (100)
)
:RequestData (
:ClientIP (192.168.1.241)
:AltClientIP ()
:BatchMode (Start)
:ClientVersion (81.070.0000)
:ClientOS ("Windows 10")
:isIdentityAgent (2)
)
)
as return buffer

And The IP-address is the one I have in my home-WLAN, and it is not a useful one for IA. IA checks connection requests after login against the IP-address registered for the user. And these connection requests will always come from the IP-address of the proxy.

So we activated XFF header addition on the proxy, and these headers indeed reach the Security Gateway. But the headers are not honored on the Security Gateway.

[PhoneBoy]

There are effectively two sources of identity here: the agent and the XFF headers.
I'm not exactly sure where XFF fits in the Conciliation priority stack, but my guess is that it's considered "lower" confidence than Identity Agent: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_IdentityAwareness_AdminGuide... 
I suspect debugging the IDAPI kernel module will bear this out: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_PerformanceTuning_AdminGuide... 

The Identity Agent cannot see the XFF header, therefore cannot communicate this information.
Not sure you can combine XFF and Identity Agent information...might be an RFE.
I do see you are engaged with TAC on this issue already.

[MatthiasHoppe]

Not sure if we really have to talk about two different sources of identity here. I would see XFF just as a special case of the Identity Agent (and by the way, we also tested Captive Portal with the same results). The conciliation behaviour is anyway not that really clear. Looking at this extract from the AdminGuide:

3

PerHostInDomain

Per-Host or Per-Entity

Per-Host

Same

If the new session arrives directly from the Identity Source , the decision is Override. If the new session arrives from an Identity Broker, the decision is based on the configured priorities of session parameters

The current session is a Per-Host session or a Per-Entity session. The new session is a Per-Host session. The same Management Server manages the two PDP Security Gateways. When the PDP Security Gateway receives the session directly from the Identity Source (not from an Identity Broker, the decision is Append. When the PDP Security Gateway receives the session from an Identity Broker, the decision is according to the configured priorities of the session parameters. Priorities of session parameters: Value0 - Office Mode IP Address Value1 - Confidence Value2 - Time to Live (TTL) Value3 - Locality Value4 - Full Session Value5 - PDP Preference

The default behaviour is Override, but in case the PDP Security Gateway receives the session directly from the Identity Source (not from an Identity Broker, the decision is Append. Which in our case should be correct, as we are connecting to the same Security Gateway from two different Identity Agents. But the decision is obviously always Override and never Append.

Currently for us it looks like the XFF headers are never used, be it when using the Agent or Captive Portal. And this is what TAC is working on.

[PhoneBoy]

Where the XFF headers fit into all this is, of course, the main question.