Clien IP address / NAT

You should be able to use X-Forwarded-For if you terminate SSL at the LTM. You can re-encrypt before the traffic leaves the LTM.

But its not HTTP traffic .... does it matter ?

Assuming you mean SNAT, this would be a pretty big undertaking to insert the client's true source into an ICA packet. Not impossible, but then you also have to consider how you'd extract it on the ICA server side. Could you:

1. Capture and log the client IP at the Web Interface (via HTTP XFF header)?
2. Capture and log the client IP (and activity) to syslog?
3. Deploy Access Policy Manager (APM) and maybe push the client IP to Citrix via Smart Access filters?

Otherwise, to keep the client IP at layer 3 and remove the SNAT, you must guarantee that the Citrix servers cannot route around the BIG-IP.

Hi Kevin,

Nope. I mean NAT:

http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_nat.html

speaking of which ... what is the difference between the both? They seem to do the exact same thing... Do I have to disable both?

to your suggestions:

1) We don't have webinterface. We have a portal that implements the webinterface api 2) Capture it where? 3) Could be ... sounds tricky

Yes, the default gateway should be the BigIP.... if we were to disable the NAT. I'm exploring other options...

So you're just NATting client traffic through the BIG-IP to the Citrix Gateway?

A NAT is, generally speaking, a multi-directional one-to-one IP mapping. It'll change the NAT (destination) address to the origin address (and back). A SNAT is a many-to-one mapping that changes the client (source) address to an address controlled by the BIG-IP - usually to enforce routing. A NAT and a virtual server, in this context, are very similar. A VIP will, by default, translate the destination address like a NAT. However a virtual server is infinitely more powerful and flexible than a NAT. At the very least you can load balance multiple back end servers, provide failover and redundanct, apply SSL encryption/decryption and other L4-L7 enhancements, and intelligently evaluate the traffic with iRules.

For your purposes, I'm assuming you're passing the ICA over SSL (port 443) traffic through the NAT. You can also do this with a virtual server. Just create a VIP with a listening address and port (443) and pool to your gateway servers (also on port 443). Do not apply a client and/or server SSL profile or any other L7 profiles. You may enable SNAT as required to change the source address.

Which gets us back to the original question. If a VIP with SNAT or NAT is translating the source address:

1. Capture and log the client IP at the Web Interface (via HTTP XFF header) - I'm also assuming your API-implemented portal is HTTP-based, yes? Enable XFF in the HTTP profile for the virtual server in front of that portal, and it'll send the client's source address in a header.

    

2. Capture and log the client IP (and activity) to syslog. - With ICA flowing through a virtual server, an iRule can log the client's source and the destination to syslog. Because you really can't see the data inside the SSL, you'd be hard pressed to log what was actually happening. You could do ProxySSL for "man-in-the-middle" SSL introspection, but then you're still dealing with a quasi-binary protocol (ICA).

    

3. Deploy Access Policy Manager (APM) and maybe push the client IP to Citrix via Smart Access filters. APM has the ability to consume Web Interface, Citrix gateway, and STA functions - very easily I might add.