Proxy SSL configured as per manual, connection reset occours

Do you have the "ProxySSL Passthrough" option enabled?

The first thing I'd do is run an ssldump capture on the client side of the F5 (client to F5).

ssldump -AdNn -i 0.0 port 443 and host [IP of VIP]

This will let you watch the SSL handshake and see where an error might be happening. For example, if the client doesn't send an RSA cipher in its ClientHello cipher list and you have the F5's client SSL profile to only accept RSA ciphers, the server (F5) will immediately send an alert and reset. If you have the Proxy Passthrough option enabled and everything starts working, that's usually a good indication that at least one side of the communication is not able to do RSA key exchanges, which is absolutely required for ProxySSL to work.

Interesting, so it looks like there's an alert after the initial handshake fails. You can't really do pool switching in an iRule like that either. ProxySSL allows a client and server to negotiate an SSL session directly, so at the end of a handshake, client and server A have a shared symmetric key. If you then divert traffic to another pool, the client doesn't know that and therefore can't communicate with that new server with its established session.

The SSL Alert protocol was never designed with any useful amount of verbosity. You're best first bet is to try to isolate where and when the alert is happening. I'd run an ssldump on both sides simultaneously to see where it's really coming from and who's actually sending it, plus what's happening immediately prior. You can sometimes derive meaning from the context.

If you disable client and server SSL on the F5, SSL tunneling, does it work?

Hello. Enable SSL log: tmsh modify /sys db log.ssl.level value Debug Enable rst cause tmsh modify /sys db tm.rstcause.pkt value enable tmsh modify /sys db tm.rstcause.log value enable

If you see in LTM logs something like "SSL Session Not Cached" maybe you are facing this https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15827.html.

Best regards.

Hello Together

Thanks to everyone for helping me out on this. We found the problem. on the virtual we had to define a default pool (as written earlier) but still had the iRule on, that selected the pool depending on the URL. Now the SSL handshake went through as it should and keys were agreed on the default pool. The iRule then joined the game and evaluated the URL and pointed even to the same pool as set on default. Bus as it seems this interferes with the established SSL session therefore the alert on the ssldump.

Anyhow, Proxy SSL is working perfectly now and solved us a lot of issues with some additional crypto that relied on the SSL keys.

Regards Andreas