Incosistent forwarding of HTTP/2 connections with layered virtual

I agree that we can't ignore that, just because it breaks our beloved concepts and new technologies often require new methods and concepts. That's fine.

However, my main caveat is, that I need to re-encrypt between tier1 and tier2 virtual, if I don't want to create a security gap or provoke legitimate discussions with the guys from information security, by transporting the traffic unencrypted between both virtuals. I'm talking about the usage of tcpdump on the BIG-IP. Yes, I'm aware, that each encryption on the BIG-IP can be dumped and decrypted. But there's a difference from the information security point of view, whether I need to invest some effort to get unencrypted traffic (which could be formally prohibitted) or if my configuration is "open like barn door".

zamroni777are you aware that this will solve the issue? Do you have practical experience with this configuration? The descriptions from F5 require customized (server) SSL profiles to "full-proxy HTTP/2". Why do you think that enabling HTTP/2 on tier2 virtual wont result in the same issue? If the same TCP connection is used, why should TLS be re-negotiated by bringing the termination to the tier1 virtual? This would be required to correctly forward the connection to the correct tier2 virtual via SNI-Routing. It's still the same (outer) TCP connection and probably the same (wildcard) certificate...