Jump to content
Welcome to our new Citrix community!

Enable client IP Header to see the actual client IP at Application side.

Recommended Posts


I have enabled client IP header for a service group (below is the referred article), but application team is not getting the client IP at application end. Is there any way to prove that NetScaler is forwarding actual client IP after enabling client IP header?




Link to comment
Share on other sites

Confirm the header name that you are setting AND the header name the backend web team is looking at.  If the backend servers are looking at the L3 Source IP packet they will still see SNIP.


On a ServiceGroup, the parameter from the cli should be -cip enabled "<headername>"

In the GUI, the service group property "[ ] Client IP Address" is actually Use Source IP setting, but the bottom setting Insert Client IP Header, with Header name is the client ip header insertion.  So you might have enabled wrong field.


Reasons why this might not work 1) wrong parameter was enabled due to confusing in the service group parameter names.  2) Existing or duplicate header is present.  3) Is there an additional proxy between clients and the ADC, resulting in an additional header requirement, 4) backend web team is assuming the source ip is in L3 and not looking at web header. 5) (If content isn't web-based, then the client ip header field will not apply)


OR you can attempt to do a REWRITE policy instead and use policy logging in syslog to "view" the action performed:

You can use a policy REWRITE to do this instead and enable logging actions to include "client.ip.src" in syslog.

Enable "user configurable log messags" in your global syslog audit parameters too to include the log action. 






Link to comment
Share on other sites

Is the servicegroup web (HTTP/SSL) or non-web?

Can you confirm the clients hit the lb vserver directly without passing through any other proxies or vpns?


If so, can you confirm if the app team is looking for the x-forwarded-for header vs the L3 source IP address?

You can try a trace or you may need a web proxy to intercept the traffic from client to vserver to make sure there isn't an existing header or a proxy adc to web backend to inspect traffic from adc to server.


Link to comment
Share on other sites

Hi Rhonda


Thanks for your prompt responses!


yes, the servicegroup is web (SSL).

yes, traffic is directly NATed to lb vserver. there is no proxy or vpns in between.


how i can find that the ntescaler is forwarding actual clinet ip?

Or is there anyway to forward the actual client IP without any header filter at Application side?

Link to comment
Share on other sites

In your case you need to run a nstrace to look at what the ADC receives client side and then what it is passing server side.

If you are NAT'ing to the ADC (by a firewall or other device), it is likely the originating client IP is not being passed to the ADC.  Your NAT device would have to do the header insertion; not the ADC.


To make things simple you can do this for HTTP traffic, or you will need to have the nstrace capture and decrypt the traffic for you.



You can then confirm the L3 source/destination IP on both the vserver side and the service side.  If the trace is decrypted, you can probably confirm the L7 header insertion.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...