All users coming from behind a corporate NAT go to a single server; why?

Short answer

NAT takes all the users in an organization out with a single source IP. Every IP-based method counts these users as a single client and sends them all to the same server: the Source algorithm, Hash persistence whose Hash key is the client IP address, and L4 Persistence and Source Hash on a Network vService. The solution is to bind persistence to a user-specific value instead of the IP: New cookie, Current cookie or Session Affinity Manager (SAM) on HTTP; Hash with a non-IP Hash key; the HDR or URL Param algorithm; RDP Cookie for RDP.

Problem: All Users of an Organization on a Single Server

Corporate networks, mobile operators and some proxies gather thousands of users behind a single public IP address. To TR7, all these users are the same client. If persistence is based on the client IP, all the traffic of the organization piles up on a single server, the other servers stay empty and that server is overloaded. The situation is verified by seeing in the Live Stats → Source IP Statistics section of the vService that the traffic comes from a few source IPs.

Settings That Cause It

Setting	vService type
LB Algorithm → Source	HTTP
Persistence → Hash, Hash Key = client IP address	HTTP, L7 TCP
L4 Persistence	Network
LB Algorithm → Source Hash	Network

Solution: Eight Methods

The methods are alternatives to each other; one is selected according to the vService type and the value in the request that identifies the user. None of them requires a change on the Backend Service side (with Current cookie, the application must already produce a session cookie).

Your situation	Suitable method
HTTP; application-independent persistence	Method 1: New cookie
HTTP; the application already produces a session cookie	Method 2: Current cookie
HTTP; monitoring and rebalancing sessions	Method 3: Session Affinity Manager (SAM)
HTTP or L7 TCP; there is a header, cookie or value that identifies the user	Method 4: Hash with a non-IP Hash key
HTTP; the user ID is in a header or in a URL parameter	Method 5: HDR / URL Param algorithm
L7 TCP; RDP server farm	Method 6: RDP Cookie
Network vService	Method 7: Removing L4 persistence and Source Hash
The settings should be made from the command line	Method 8: WEB-CLI

Method 1: New cookie Recommended

• How it works TR7 adds its own persistence cookie (default name TR-C) to the first response; since each user's browser carries a separate cookie, users coming from the same IP are distributed to different servers and stay on their own servers.
• Where it is opened vService → Details → LB Algorithm → Persistence → New cookie
• Requirement The client storing cookies; an algorithm that is not self-persistent
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the vService edit form

The Load Balancer → Load Balancer vService List steps are followed, the vService is selected and the Edit button is clicked.

2

Adım 2 Open the LB Algorithm box

The Details switch is turned on; if the LB Algorithm box is not checked, it is checked.

3

Adım 3 Select an algorithm that is not self-persistent

If a self-persistent algorithm such as Source is selected in the Algorithm list, a non-persistent algorithm (e.g. Round Robin, Least Connection) is selected instead. While a self-persistent algorithm is selected, the Persistence field does not appear.

4

Adım 4 Select New cookie

New Cookie is selected in the Persistence field. If Cookie Name is left empty, TR-C is used; Cookie Max-Idle (default 30 minutes) and Cookie Max-Life (default 8 hours) are changed if needed.

5

Adım 5 Save

The Save button is clicked. The progress of applying the change is followed from the sync indicator at the bottom right of the screen. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize. Existing users receive the cookie on their next request and start to be distributed.

Verification

1DistributionTR7 side

The Current Sessions values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedSessions on more than one server

2CookieClient side

The response headers are checked in the browser's developer tools.

ExpectedSet-Cookie: TR-C=…

Method 2: Current cookie

• How it works The session cookie produced by the application (e.g. JSESSIONID, PHPSESSID) is used; each user's session stays on its own server.
• Where it is opened vService → Details → LB Algorithm → Persistence → Current Cookie
• Requirement The application producing a session cookie; an algorithm that is not self-persistent
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Prepare the algorithm

Steps 1–3 of Method 1 are applied: the vService is opened for editing, the LB Algorithm box is checked and an algorithm that is not self-persistent is selected.

2

Adım 2 Select Current cookie

Current Cookie is selected in the Persistence field, and the name of the application's session cookie (e.g. JSESSIONID) is written in the required Cookie Name field.

3

Adım 3 Save

The Save button is clicked.

Verification

1DistributionTR7 side

The Current Sessions values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedSessions on more than one server

Method 3: Session Affinity Manager (SAM)

• How it works It is cookie-based, stateful persistence; sessions are tracked in a mapping table and can be rebalanced among the servers when needed.
• Where it is opened vService → Details → LB Algorithm → Persistence → Session Affinity Manager (SAM)
• Requirement An algorithm that is not self-persistent; at least two Backend Services on the vService
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Prepare the algorithm

Steps 1–3 of Method 1 are applied.

2

Adım 2 Select SAM

Session Affinity Manager (SAM) is selected in the Persistence field. Cookie Source is TR7 Generates by default; the cookie name is written in the required Cookie Name field (placeholder TR7SID). The other fields are in the SAM configuration parameters section.

3

Adım 3 Save

The Save button is clicked.

Verification

1DistributionTR7 side

The Current Sessions values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedSessions on more than one server

Method 4: Hash with a Non-IP Hash Key

• How it works Hash persistence produces the persistence key from the Smart Variables in the Hash Key list; a user-specific value (e.g. a header or cookie) is used instead of the client IP address.
• Where it is opened vService → Details → LB Algorithm → Persistence → Hash → Hash Key
• Requirement A user-specific value being present in the request; an algorithm that is not self-persistent
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Prepare the algorithm

Steps 1–3 of Method 1 are applied.

2

Adım 2 Select Hash

Hash is selected in the Persistence field.

3

Adım 3 Change the hash key

The client IP address is removed from the Hash Key list, and a user-specific Smart Variable (e.g. a header or cookie value) is added in its place. Hash Key List Size (default 3,000,000) and Hash Key Expire Time (default 7 days) are changed if needed.

4

Adım 4 Save

The Save button is clicked.

Verification

1DistributionTR7 side

The Current Sessions values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedSessions on more than one server

Method 5: HDR / URL Param Algorithm

• How it works The algorithm selects a server with the hash of the value of an HTTP header or URL parameter that carries the user ID; the same user goes to the same server.
• Where it is opened vService → Details → LB Algorithm → Algorithm → HDR / URL Param
• Requirement The ID being present in the header or parameter on every request
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the LB Algorithm box

Steps 1–2 of Method 1 are applied.

2

Adım 2 Select the algorithm

HDR or URL Param is selected from the Algorithm list. For HDR, the header name (e.g. X-User-ID) is written in the required HDR Name field; for URL Param, the parameter name is written in the required URL Parameter to Use field. Requests that do not contain the header or parameter are distributed to the servers in turn, and there is no persistence for these requests.

3

Adım 3 Save

The Save button is clicked.

Verification

1DistributionTR7 side

The Current Sessions values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedSessions on more than one server

Method 6: RDP Cookie

• How it works A server is selected according to the user name cookie in the first packet of the RDP connection; different users coming from the same NAT IP go to different servers.
• Where it is opened L7 TCP vService → Details → LB Algorithm → Algorithm → RDP Cookie
• Requirement The RDP client sending a cookie
• vService type L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the LB Algorithm box

Steps 1–2 of Method 1 are applied on the L7 TCP vService.

2

Adım 2 Select RDP Cookie

RDP Cookie is selected from the Algorithm list, and mstshash is written in the required RDP Cookie Name field.

3

Adım 3 Save

The Save button is clicked.

Verification

1DistributionTR7 side

The Current Sessions values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedSessions on more than one server

Method 7: Removing L4 Persistence and Source Hash

• How it works Since a Network vService does not see the request content, it cannot establish user-specific persistence; by removing IP-based persistence, users are distributed per connection.
• Where it is opened Network vService → Details → LB Algorithm → L4 persistence / algorithm list
• Requirement The application not requiring persistence across connections
• vService type Network

Step-by-Step Configuration

1

Adım 1 Open the vService edit form

The Load Balancer → Load Balancer vService List steps are followed, the Network vService is selected and the Edit button is clicked; the Details switch is turned on.

2

Adım 2 Turn off L4 persistence

The L4 Persistence switch in the LB Algorithm box is set to Disabled.

3

Adım 3 Change the algorithm

If Source Hash is selected in the algorithm list, Round-Robin, Weighted Round-Robin, Least-Connection or Weighted Least-Connection is selected.

4

Adım 4 Save

The Save button is clicked. On a Network vService, every save restarts the vService (Network vService · Save); the change is made at a low-traffic time. If persistence is required, the service is published with an HTTP or L7 TCP vService and one of Methods 1–6 is used.

Verification

1Connection distributionTR7 side

The New Connection/s values of the Backend Services are compared on the Live Stats screen of the vService.

ExpectedConnections on more than one server

Method 8: WEB-CLI

• How it works The algorithm and Persistence are written from the command line; the --persistence field takes the value tr7Cookie (New cookie), serverCookie (Current cookie), dynamicPersistence (Hash) or sam (SAM).
• Where it is openedWEB-CLI → lb service update
• Requirement WEB-CLI access; the ID of the vService (seen with lb service list)
• vService type HTTP (only dynamicPersistence on L7 TCP)

Step-by-Step Configuration

1

Adım 1 Write the algorithm and Persistence

An algorithm that is not self-persistent is written together with New cookie; the ID of the vService is written in place of <vService>:

lb service update id <vService> --algorithm roundrobinNoWeight --persistence tr7Cookie

Verification

1RecordWEB-CLI

The vService record is displayed.

Commandlb service show <vService>

ExpectedThe value of the persistence field is tr7Cookie

Common Mistakes

• Looking for Persistence while Source is selected. While a self-persistent algorithm is selected, the Persistence field does not appear; the algorithm is changed first.
• Leaving Hash persistence with the client IP address key. If the Hash key is the client IP address, the problem persists.
• Expecting cookies from clients that do not store cookies. API clients and some mobile applications do not store cookies; for them, header-based Hash or HDR is used.
• Trying to solve it with Trusted Proxy. Plain NAT does not add an X-Forwarded-For header; the real user IP is not present in the request.

How it is done in the documentation

• HTTP (L7) vService · Session Persistence
• HTTP (L7) vService · Session Affinity Manager (SAM)
• Network vService · L4 Persistence
• Live Stats · Source IP Statistics

Related questions

• Can the Source algorithm be used instead of persistence?
• How is persistence achieved for clients that do not support cookies (mobile apps, API clients)?
• Why is traffic not distributed evenly across the servers?