F5 Big-IP: SSL Persistence

Exam Topics

• F5CAB3
  • F5CAB3.01
    • Apply appropriate persistence profile

Introduction

In the Persistence course, we have reviewed case where we want the user to be redirected to the same backend server on each subsequent request.

With Source Address Affinity and Cookie persistence, you can cover most persistence requirements. However, both methods have limitations:

• Source Address Affinity is simple to implement but consumes memory on the BIG-IP and can be ineffective when many users share the same public IP address (for example behind NAT, proxies, or VPN gateways).
• Cookie persistence solves this problem by uniquely identifying users at the HTTP layer, but it only works for HTTP traffic or HTTPS traffic that is decrypted by the BIG-IP.

There are situations where:

• Source IP persistence is not granular enough
• Cookie persistence cannot be used because the application is not HTTP-based or traffic cannot be decrypted

In these cases, if the application uses SSL/TLS, you can use the SSL persistence profile.

How SSL persistence works

If your application is not HTTP, or Source Address Affinity is not ideal because multiple users may share the same IP address, you can consider using the SSL persistence profile.

SSL persistence relies on how SSL/TLS connections operate, using SSL session information as the persistence key. Because of this, the main prerequisite is that the Virtual Server handles SSL/TLS traffic.

When a client establishes an SSL/TLS connection, a handshake occurs between the client and server. As part of this process, the server assigns an SSL Session ID to the client. This Session ID allows the client to resume sessions later and speeds up future SSL handshakes.

Because this Session ID is exchanged in cleartext during the SSL handshake, the F5 BIG-IP can inspect it and use it for persistence.

The process works as follows:

1. The client establishes an SSL connection.
2. The BIG-IP performs a load-balancing decision.
3. The BIG-IP observes the SSL Session ID and creates a mapping between this ID and the selected pool member in the persistence table.
4. When the client reconnects and presents the same SSL Session ID, the BIG-IP checks its persistence table.
5. If a match is found, the connection is directed to the same backend server.

In this example, the client establishes an SSL/TLS connection to a server through a Virtual Server. During the initial handshake, the client sends a Client Hello message, which includes parameters used to negotiate the SSL session (such as supported ciphers). Since this is the first connection, no SSL Session ID is provided by the client.

The F5 BIG-IP then performs a load-balancing decision and forwards the connection to Server 1.

When the server responds with a Server Hello, it assigns and returns an SSL Session ID. The F5 BIG-IP observes this value in the handshake and creates a persistence mapping in its persistence table, associating the Session ID with Server 1.

When the client initiates a new SSL connection, it includes the previously received SSL Session ID in the Client Hello message as part of the session resumption process.

Because the Client Hello is not encrypted, the F5 BIG-IP can inspect it and extract the Session ID. The BIG-IP then looks up this value in its persistence table.

An entry is found mapped to Server 1, the BIG-IP directly forwards the connection to that server. No new load-balancing decision is performed, ensuring that the client is consistently directed to the same backend server.

The key point to understand is that when a client establishes a connection to an SSL server, the server assigns an SSL Session ID during the initial handshake. This exchange occurs in clear text, before encryption is fully established.

On subsequent connections, the client may reuse this Session ID to resume the SSL session, reducing the overhead of a full handshake and improving performance.

The F5 BIG-IP uses this SSL Session ID as the persistence key, allowing it to consistently direct the client to the same backend server.

Note: in this persistence method, the client IP address is not used at any stage of the persistence decision process.

Because this is a general SSL/TLS behavior, SSL persistence can be used for many encrypted applications. It is especially useful for HTTPS, particularly when traffic is not decrypted on the F5 BIG-IP, which prevents the use of cookie persistence. It can also be used for other SSL-based services such as FTPS, LDAPS, SMTPS, IMAPS, and similar protocols.

Persistence Table

You can review the persistence entry of the SSL persistence using the main command :

root@(mybigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# show /ltm persistence persist-records all-properties
Sys::Persistent Connections
ssl-session-id - 192.168.120.11:443 - 192.168.110.10:80
TMM 0
Mode ssl-session-id
Value 32e83402862ca8e61ab05c0bee75506f6690109c35546c78edc56172be05a07f
Age (sec.) 86
Virtual Name /Common/UnmonitoredVS
Virtual Addr 192.168.120.11:443
Node Addr 192.168.130.10:443
Pool Name /Common/VM_pool
Client Addr 192.168.110.10
Owner entry not mirrored

You can review that the persistence mode in use is the ssl-session-id.
You can also review that the value of the record is a long hexadecimal string which represent the SSL session ID, and to which pool member it is mapped (192.168.130.10:443).

Conclusion

The SSL persistence profile can be useful when the application is not HTTP-based or when Source Address Affinity does not provide enough granularity due to shared client IP addresses.

It can be used with any SSL/TLS-based protocol, such as HTTPS, FTPS, LDAPS, SMTPS, or IMAPS, making it applicable beyond traditional web traffic.

However, this method is limited to TLS 1.2 and earlier, since TLS 1.3 no longer relies on SSL Session IDs in a way that supports persistence. In addition, modern clients and applications may not consistently reuse session identifiers, which can reduce its reliability.

Despite these limitations, SSL persistence remains valuable because, unlike cookie-based persistence, it can be used on non-HTTP Virtual Servers and on encrypted traffic, offering more precision than Source Address Affinity in specific use cases.