SSL Forward Proxy, iRules and Client Hello

Hi Kevin, yes it's SSLO. The server profiles are the SSLO created one (A) + child profile (B).

I have tried a different tact.. moving the initial SNI extraction to LTM policies, and I have been able to intercept the CH reliably using LTM policies, pushing it into a variable and using that in the iRule, but I still get connection resets.

It appears the browser(s) (edge/chrome) do not resend SNI for subsequent requests to the same page, perhaps because they are using a different client src port they are not persisting to the original SNI sessions 'mapping' to the correct SSSL profile, the handshake fails occur on sessions from different client src ports than the initial CH/SNI.

The first connection works fine, e.g. open browser > enter URI > web page returned OK.

Subsequently refreshing that same site is what triggers the HS fail/connection reset.

A gap in my understanding is how the F5 would handle this behaviour when using the SNI option in the profile (which is not an option as the pattern matching is very limited e.g. to only matching to a single depth in the SNI e.g. server name id *.domain.com would only match test.domain.com not host.test.domain.com :-(

If there was an iRule equivalent to the built in SNI matching functionality, but with better pattern matching (or at least wildcarding) that could work, or a way to normalise SNI information somehow before it reaches that logic decision in the SSSL selection?