Product Documentation
ADC
14.1-Current Release 13.1
View PDF

Client source IP address tracking

March 5, 2026
Contributed by: 
C

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.

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
<!--NeedCopy-->

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.SRC)" DENY
<!--NeedCopy-->

Expression:

    AAA.USER.SOURCEIP.NE(CLIENT.IP.SRC)
<!--NeedCopy-->
  • XFF based protection:

Command:

add authorization policy session_hijack_Block "AAA.USER.XFFIP.NE(CLIENT.IP.SRC)" DENY
<!--NeedCopy-->

Expression:

 AAA.USER.XFFIP.NE(CLIENT.IP.SRC)
<!--NeedCopy-->
  • Using the VALIDATE_CLIENTIP expression:

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
<!--NeedCopy-->

Expression:

 AAA.USER.VALIDATE_CLIENTIP.NOT
<!--NeedCopy-->

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.
Client source IP address tracking
March 5, 2026
Contributed by: 
C
March 5, 2026
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.