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.