OneConnect with SNAT on F5

OneConnect, in F5’s BIG-IP, is a relief when your back-end servers become stressed by too many TCP negotiations. OneConnect can increase throughput by managing and reusing TCP connections created between the BIG-IP system and the back-end pool members. It works with HTTP Keep-Alives, and allows TCP connections to be held open for reuse by other clients.

Configuration Options

With a routed configuration you are not using SNAT. Instead, you have the default gateway of all your servers set as the internal self IP address of the BIG-IP. In this scenario your back-end servers see the IP address of the clients that are connecting as the source address. When returning an answer to the client, the servers send it to their default gateway, the F5’s internal self IP. The BIG-IP then sends the response off to the client.

With OneConnect applied in this configuration you have control over what connections reuse open TCP connections from the Reuse Pool. The OneConnect mask is the mechanism to control this, also called the Source Prefix Length. The image below illustrates how this works.

The Source Prefix Length (One Connect Mask) determines what connections from the Reuse Pool are eligible for reuse by a new client connection.

Complications with SNAT

With a SNAT (Auto Map) configuration, you don’t set the default gateway on your back-end servers to be the BIG-IP. Instead, you translate the clients original IP address to that of your internal self IP. That ensures that all responses will return to the client via the BIG-IP.

With OneConnect applied to your VIP in this configuration, BIG-IP will always determine a connection to be eligible for reuse. OneConnect will apply the mask to the translated IP (which is always the same). If you are using SNAT Auto Map, you are effectively making your OneConnect Mask 0.0.0.0 without realizing it.

If instead of Auto Map you opted for a SNAT Pool or translation via iRule, your Reuse Pool could be divided by each translation IP. This might help in some corner case scenarios, but probably over complicates most situations.

Order of Operations with SNAT & OneConnect

The flow information F5 publishes on the topic is as follows:

  • First, TMOS performs the SNAT.
  • TMOS then applies the OneConnect Mask.
  • Finally, the system determines whether or not the address is available for a connection reuse.

We know that if you are SNATing to your internal self IP it will always use the same source address to your back-end servers. This is what the OneConnect Mask uses, so it will always reuse connections. If an application expects a single TCP connection to be a single user, that can be bad. This can be especially confusing when you think you have control over the reuse of the TCP connections.

F5 has published two KB articles with information concerning SNAT and OneConnect together:

K7208: Overview of the OneConnect profile

On that page they say this:

“When a new connection is initiated to the virtual server, the BIG-IP system performs SNAT address translation on the source IP address, and then applies the OneConnect source mask to the translated SNAT IP address to determine whether it is eligible to reuse an existing idle connection.”

F5 KB Article K7208

There is then a link on that page to:

K5911: Managing connection reuse using OneConnect source mask

On that page they say this:

“If secure network address translation (SNAT) is configured, the BIG-IP system performs SNAT on the source IP address and then applies the OneConnect source mask to the translated SNAT IP address to determine whether it is eligible to reuse an existing idle connection.”

F5 KB Article K5911

Reading just the F5 documentation can put you in a loop of clicking back between those two articles. Hopefully this information has helped out and made their explanation and the issues to look for more clear. Let us know in the comments if you have other questions!