Change server SSL profile based on HTTP content

Essentially the oneconnect profile is used IN ADDITION to what you have already configured in your irule/LTM profile. Without a oneconnect profile, your only option is to create a brand new serverside connection every time your header changes. With a oneconnect profile, you can have persistent serverside connections to your two destinations "kept open" and then, depending on the header in the client request, it will just send it to an available connection instead of creating a new one.

That said, oneconnect is not going to pipeline multiple clients to a single server connection, it'll only use an existing connection if that connection is IDLE. If there are no IDLE serverside connections, it'll create a new one, similarly, if you don't meet the mask (for example a /32 mask means clients can only reuse their own connections, whereas a /24 you could let clients with source ips in the same subnet share connections with each other) criteria, it'll also create a new connection (even if there is an idle one for a different mask). The interaction of all this various logic probably explains what you observed as "inconsistent".

It is definitely one of the stranger profiles to understand and tune, but it sounds to me like if you keep your current setup and just add a /32 oneconnect, and it has a timeout that is, say, about twice as long as what you would estimate as the average time between user requests with headers for DIFFERENT destinations, you'd probably see some performance gain.

On the other hand, you can just create new connections every time like you are now, if you have the memory to spare. As long as your tcp idle timeout is reasonable and connections get culled regularly, the impact on the box isn't serious (although your users will obviously experience the delay of a tcp + tls handshake every time the headers switch)

Thanks again for the update :-)

Regarding the mask - I had left it at default because the VS uses a SNAT pool with a single IP. My understanding is that oneconnect examines the post SNAT source IP, so essentially the mask has no impact for my setup? I did try with /32 just to check but saw no difference.

As for my question on what 'level' the oneconnect reuse pool operates at - looking at the help section in the oneconnect profile page on the F5 GUI it looks like it is at the VS level. I think that will likely cause me a problem for the current setup (not tied to that setup though, happy to change it :-). I use different pools so that an iRule can assign a server SSL profile based on a 1-1 mapping between the pool name and the SSL profile to use.

To me the following is what I _suspect_ is happening:

- Initial traffic sent to pool A and server side connection setup correctly using server SSL profile A

- When HTTP header change happens, the traffic policy instead chooses pool B

- Oneconnect kicks in at this point and sees that the required connection is from SNAT IP to website IP port 443. This is on pool B but that was chosen by the VS with the oneconnect profile, and the mask covers the source IP OK, so this connection is eligible to be switched onto a reused TCP connection.

- At the TCP level i.e. IP/port this new connection request in pool B exactly matches the existing connection from pool A. Also at this point the server SSL profile would match, because I can't assign that in the iRule until a serverside event (please correct me if I have that wrong). This is why I asked if oneconnect takes the likes of SSL into account to differentiate between connections or if it is just on the lower level protocol.

- Oneconnect switches the traffic onto the existing connection, and the SERVER_CONNECTED event never triggers, which is where I would have assigned server SSL profile B

So basically all my traffic is just going over that single connection, and any time that HTTP Header X = B the traffic is actually sent on the 'wrong' pipe.

I can see how oneconnect would work if I could somehow confine it to a pool rather than a VS. Essentially I would then just use it to keep a connection up per pool, and I would know that each connection had been established using the correct SSL profile, so any traffic directed to the pool by the traffic policy would definitely be sent across a 'correct' pipe. Is this possible?

Sorry, there is a lot to clarify and explain and possibly correct in that and I think we are getting beyond the scope of DevCentral. As I mentioned before, the name, usage, and configuration of a oneconnect profile is confusing and a little unintuitive. If you are expecting to see "one" connection per pool, you will definitely think it is behaving incorrectly, because it is not a "tunnel" or a "pipe" like you are saying. It is a tcp connection and it will never be used for multiple requests at the same time, it must be idle or a new connection will be created. In fact, some people put the default oneconnect profile on vips hoping for a "one click" performance improvement only to find they now have more serverside connections than before (especially if their non-oneconnect vip was layer 4 or was doing pipelining etc).

Ultimately, there is only so much that can be done here. If you are able to get something that works for you taking this conversation (and others here) into consideration, great. If not, you should probably work with someone with whom you can share specific config details and pcaps and get personalized consulting that should not be done over public internet.