Client source IP address tracking

Last published : Sep 22, 2026
NetScaler® supports validating the client IP address after validating the NSC_TMAS cookie to ensure that requests are generated from the same client IP address. If a client request comes from a different source IP, even with a valid session cookie, the session is discarded, and the user will be prompted to log in again. This adds an extra layer of security and verification to the authentication process.
Related information

Configure client source IP address tracking for sessions

To support this functionality, two new PI expressions AAA.USER.SOURCEIP and AAA.USER.SOURCEIPV6 is introduced. These expressions return the source IPV4/IPV6 address stored in the AAA-TM or AAA Session. You can create an authorization policy to validate the client's source IP address for each request that comes with a cookie by using these expressions.
Note:
The AAA.USER.SOURCEIP and AAA.USER.SOURCEIPV6 expressions are only available in NetScaler 14.1-25.x, 13.1- 53. x, 13.1-37 FIPS and later releases.
To configure authorization policy using PI expressions:
At the command prompt, type:
add authorization policy <policy_name> <expression> <action>
Example:
add lb vserver <LB_VS> HTTP <LB-VIP> <PORT> -AuthenticationHost <AUTH_VIP> -Authentication ON
add authentication vserver <AUTH_VS> SSL <Auth-VIP> <PORT>
add authorization policy  validateClientIP "AAA.USER.SOURCEIP.EQ(CLIENT.IP.SRC).NOT" DENY
bind lb vserver <LB_VS> -policy validateClientIP -priority 1

Client IP address validation using X-Forwarded-For (XFF) in AAA sessions

In NetScaler Authentication, Authorization, and Auditing (AAA) deployments, attackers might attempt to reuse stolen session cookies to hijack authenticated sessions. To mitigate this risk, NetScaler captures and associates a client's real IP address with their authenticated AAA session.
Earlier, NetScaler relied on the client’s source IP address to validate sessions. To better support modern network topologies, NetScaler now associates the IP address in the X-Forwarded-For header as a user attribute, along with the client IP address seen in the IP address header, to optimize proxy and NAT-based deployments.

Benefits

  • Stronger session integrity: Enforces security even when traffic passes through intermediate devices.
  • Modern topology support: Ideal for AAA deployments behind NAT or proxy devices.
  • Reduced attack surface: Significantly lowers the risk of session hijacking by preventing session reuse from different client networks.

Prerequisites

Before implementing XFF-based validation, ensure that you have:
  • Trusted proxy infrastructure.
  • Proper responder or authorization policies configured on Gateway or AAA.

How it works

When a user authenticates, NetScaler extracts the first IP address from the XFF header and stores it within the AAA session. This stored IP address is then compared against the XFF IP address seen during subsequent resource access.

Key policy expressions

  • AAA.USER.XFFIP: Exposes the stored XFF IP address.
  • AAA.USER.XFFIPV6: Exposes the stored XFF IPv6 address.
  • AAA.USER.VALIDATE_CLIENTIP: A boolean expression that compares the XFF IP address stored at authentication with the one seen during access. If no XFF information is available, it automatically falls back to a source IP address comparison.

Configuration examples

The following commands and expressions are used through the authorization policy infrastructure to protect the deployment:
  • SOURCE_IP based protection:
Command:
add authorization policy session_hijack_Block "AAA.USER.SOURCEIP.NE(CLIENT.IP.SOURCE)" DENY
Expression:
AAA.USER.SOURCEIP.NE(CLIENT.IP.SOURCE)
  • XFF based protection:
Command:
add authorization policy session_hijack_Block "AAA.USER.XFFIP.NE(CLIENT.IP.SOURCE)" DENY
Expression:
AAA.USER.XFFIP.NE(CLIENT.IP.SOURCE)
  • Using the VALIDATE_CLIENTIP expression:
This boolean expression compares the XFF IP stored at authentication with the one seen during access, falling back to source IP if no XFF info is available.
Command:
add authorization policy session_hijack_Block "AAA.USER.VALIDATE_CLIENTIP.NOT" DENY
Expression:
AAA.USER.VALIDATE_CLIENTIP.NOT

Limitations

  • Session cookie theft from the same client IP address cannot be detected.
  • Replayed or forged XFF headers might bypass validation.
  • XFF tampering can result in denial-of-service for valid users.
  • This feature reduces risk but does not eliminate all hijacking scenarios.