Source-Address Persistence Behind an Upstream NAT
A 2,000-user SaaS application is published through an LTM virtual server 10.10.10.100:443. Clients reach it through a corporate secure web gateway that source-NATs all user traffic to 10.40.0.5. The virtual server uses SNAT automap toward the pool. The pool has three members: 10.10.20.11:443, 10.10.20.12:443, and 10.10.20.13:443. The virtual server uses a source-address persistence profile with a 1,800-second timeout. Users report that once they log in, they stay on one member even after that member's response time degrades; other members are nearly idle. tmsh show ltm persistence persist-records shows a single active source-address record for 10.40.0.5. Connection statistics show member 10.10.20.11 with about 1,900 connections, while the other two have fewer than 30 each. The application supports HTTP cookies but does not require affinity for static content. Security still wants SNAT for outbound pool-member connections. No iRules are deployed.
1. Why is source-address persistence collapsing all users onto one member? Is the BIG-IP's SNAT automap the cause?
Read the worked answer
Reasoning
The persistence key is the client source address as seen by the LTM. The upstream secure web gateway translates every user to 10.40.0.5, so the LTM sees one source address for all 2,000 users. Source-address persistence creates one persist record for 10.40.0.5 and maps every request to the same member. The single record and the 1,900/30/30 connection split are consistent with that. The BIG-IP's own SNAT automap is not the cause; it is applied on the pool-member side and is there to satisfy the return path. The upstream NAT is the visibility problem.
2. Design a persistence configuration that spreads new users and still keeps session affinity, while retaining SNAT.
Read the worked answer
Reasoning
Because the application is HTTP and supports cookies, use cookie-insert persistence on the virtual server and remove the source-address persistence profile. A cookie such as BIGIP_SaaS with a 1,800-second timeout gives each user a unique persistence key, so new users are balanced across all three members and later requests return to the same member. Keep SNAT automap or a sized SNAT pool. Do not configure source-address as a fallback: with the upstream NAT it would recreate the collapse for clients that lose or refuse the cookie. If a small non-cookie client population must be supported, handle it with a separate virtual server or an iRule keyed on a trustworthy application identifier, not on the NATed source address.
3. After the change, a few clients still stick to a single member. What would you check, and what fallback would you avoid?
Read the worked answer
Reasoning
Check whether those clients accept the inserted cookie, whether the application overwrites or renames the cookie, and whether the cookie domain/path matches the request. Also confirm that the virtual server has only one persistence profile active; a leftover source-address profile can take precedence. Avoid a source-address fallback because the secure web gateway makes it meaningless. If those clients cannot use cookies, use an application-supported identifier or a separate VIP with an explicit design, rather than silently falling back to a key that maps thousands of users to 10.40.0.5.