The State Of HTTP/2 Full Proxy With F5 LTM

Articles Community CodeShare
1
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’.

In this article, I will attempt to summarize the known challenges of an HTTP/2 full proxy setup, point out possible solutions, and document known bugs and incompatibilities.

Most major browsers had added HTTP/2 support by the end of 2015. However, I hardly ever see F5 LTM setups with HTTP/2 full proxy configured.

The time has come to configure LTM with HTTP/2 as well.

I would of course welcome any additions or comments. I will keep this article up-to-date. You can find the changelog at the bottom.

Why HTTP/2?

HTTP/2 is a major improvement over HTTP/1. HTTP/2 decrease latency to improve page loading speed in web browsers by considering header compression and multiplexing requests over a single tcp connection. Accelerate applications is one point that we all want to achieve with an ADC.

Speed is important, but security is more important. HTTP/2 offers us more security out of the box by making HTTP Request Smuggling almost impossible. That is the second point that we all want to achieve.

Read more about the Desync Endgame: HTTP/1.1 Must Die

How to configure a HTTP/2 Full Proxy Setup

Activating HTTP/2 Full Proxy is simple:

  1. Configure a ClientSSL and a ServerSSL Profile with disabled renegotiation. SSL Renegotiation is not supported by HTTP/2 and also not for TLS1.3.
  2. Configure a client-side and a server-side HTTP/2 Profile, ensure that “Enforce TLS Requirements” is enabled. It is very likely that you must increase the “Number of streams per connection” and “Header table” size settings.
  3. Configure the Virtual Server with client-side and server-side SSL profile and HTTP/2 profile and active the “HTTP MRF Router” option.
  4. Use a HTTP/2 Monitor for the pools: K29224049: Overview of the BIG-IP HTTP/2 monitor

With this setup the Virtual Server speaks HTTP/1 and HTTP/2 for client-side and server-side connections.

F5 References:

Some common errors

Enable stream error logging

Not easy to find, because it is only mentioned in a Bug Report.

Discovered issues with this setup

If everything were working as usual, I wouldn’t have written this article. I tried HTTP/2 the first time with 15.1 and I quickly stopped implementing this for various reasons. I was hoping that a few years later, things would have improved somewhat.

F5 itself has a support document with some gotchas: K95032535: Detecting the use of and troubleshooting HTTP/2 traffic on the BIG-IP

Notable ones for my setups are:

APM is NOT supported

An APM profile can NOT be attached to a Virtual Server with a Full Proxy setup. When I discovered this, I thought it was a bug, but F5 confirmed it.

No security for gRPC

gRPC uses natively HTTP/2, we can not secure the this protocol with ASM or APM.

Websocket Profile not supported

You can not attach a Websocket Profile to a HTTP/2 enabled Virtual Server. HTTP/2 and Websocket support are exclusive options. I do not know why this can not be configured, but a Websocket profile is required as soon as you attach an ASM policy.

It would be useful to have a single Virtual Server that can handle HTTP/2 connections and Websockets over HTTP/1.

There is now a RFE for to support this, the Internal Tracking ID is: RQ-LTM-0002399.

F5 References:

No possibility to enforce server-side HTTP/2

I have no clue how to enforce server-side HTTP/2 to mitigate the security issues with HTTP/1. However, HTTP/2 is automatically preferred.

Bot Defense blocks

Bot defense blocks traffic with anomaly Invalid HTTP Headers Presence or Order. The root cause is that the headers are all lower case in HTTP/2.

Missing iRule Event

The “HTTP_REQUEST_SEND” event is not triggering in a HTTP/2 full proxy setup and there is no full replacement event for it. You must rewrite your iRules to not use this event. I have not found any documentation about this, but F5 support confirmed this and it will not be fixed.

ASM unblocking not working

A simple “ASM::unblock” throws an error and the connection is reset. F5 support confirmed that this is a bug.

iRule Variable Scope issues

Kai has discovered this issue some time ago: Dealing with iRule $variables for HTTP2 workload while HTTP MRF Router is enabled

F5 References:

I opened a support call to clarify the observations and point out the desired behavior and there is a bug or not. The outcome was that a variable set in the HTTP_REQUEST event should never been seen in the server side events like SERVER_CONNECTED. That this is working if you not set a variable in the CLIENT_ACCEPTED event is the bug.

We have the same variable scope for client-side and server-side of the tcp connection. Events like CLIENT_ACCEPTED, CLIENTSSL_CLIENTHELO and SERVER_CONNECTED are sharing the scope.

We have then for each HTTP/2 stream another variable scope that is a carbon copy of the parent tcp connection scope. Events like HTTP_REQUEST and HTTP_RESPONSE_RELEASE are sharing this scope.

At time of writing I found no workaround for this problem and F5 engineering is working on this case.

F5 Internal Bug ID is: 2064069

Conclusion

I’m sorry to say this, but I can not recommend a HTTP/2 Full Proxy setup. There are far too many bugs and not supported features in the HTTP/2 Full Proxy implementation.

Changelog

  • Update 2026-03-11
    • Bug ID 1111377 (Thanks ​Alexandre)
  • Update 2026-03-10
    • RFE for Websocket Profile (Thanks Alexandre)
  • Update 2026-02-25
    • Add Bug ID for iRule Variable Scope Issues
  • Update 2026-01-29
    • No APM Profile can be attached (Discovered by Kai)
    • GRPC is not supported (Discovered by Nikoolayy1)
    • TLS1.3 only is not supported (Discovered by Nikoolayy1)
    • Stream error debugging
  • Update 2026-02-02
    • gRPC section (Hint from F5 Support)
    • HTML Content Profile (Hint from F5 Support)
6 Likes
2

Excellent summary of where we are at with HTTP/2 the moment.

1 Like
3

Hey Juergen,

thanks for this great article! :+1:

You can add Bug ID 1196505 (see BIG-IP 17.5.1.3 Fixes and Known Issues | BIG-IP Documentation) to the list of known issues as well, which makes Full-Stack HTTP/2 almost unusable in many environments. :unamused_face:

Hit me today and feels like a little snitch: Reset on the server-side, without releasing the request on the client-side. ASM logs even report the response status code. :face_with_crossed_out_eyes:

Greetings,

Sven

2 Likes
4

F5 needs to work on AWAF with HTTP/2 for 21.x hopefully as  myF5 gRPC is also not supported on HTTP/2 but Nginx App Protect WAF that is again the bd process as BIG-IP AWAF supports it and I find that strange.

2 Likes
5

Hi Sven,

I discovered this Bug already in the combination with the ASM::unblock in iRules.

The known issues list is terrifying long…

6

Ah…sorry. I’ve overseen this reference. But at least I found it outside of iRules. :grinning_face_with_smiling_eyes:

However, I hardly ever see F5 LTM setups with HTTP/2 full proxy configured.

Maybe because of the terrifying long list of known issues or bad experience :wink:. I’ve never had good results with HTTP/2, neither measurable nor felt. Either because of buggy HTTP/2 configuration in the backend or because of the perceived lack of support on the BIG-IP or known issues…

1 Like
7

Ah…sorry. I’ve overseen this reference. But at least I found it outside of iRules.

This makes it even worse.

I hope this article will encourage F5 to prioritize addressing the issues with HTTP/2. In any case, I would prefer to see the known issues list worked through rather than new features being introduced.

1 Like
8

To add to this wonderful list Juergen_Mang​ TLS1.3 with HTTP/2 has issues

Bug ID 1341093  and

1 Like
9

Do I read it correctly? “TLS1.3 only” does not work with HTTP/2?

10

An updated article is coming soon, it requires only the approval.

11

Juergen_Mang​  Still no official statement from F5 but from what I get TLS1..3 does not work with HTTP/2 and I tested TLS1.2 cipher group with “ECDHE-RSA-AES256-GCM-SHA384/TLS1.2, DTLS1.2” and I got again the error “profile ‘/Common/tls-1-2-tes’; cipher ECDHE-RSA-AES128-GCM-SHA256 must be available”.

This suggests that TLS1.2 is with limited support for HTTP/2  as well​:red_question_mark:

1 Like
12

Nikoolayy1​

I am curious, let me test in my lab setup.

Changed my Cipher group to:

image_345264.png

And I get this error (the same as you?)

image_345264.png

Also disables TLS1.2 with the options in the ssl client profile does not work. It seems TLS1.2 is required for HTTP/2 Full Proxy Setups. Enabling only TLS1.2 and disable all other versions works.

As far I know the RFC says: Implementations of HTTP/2 MUST use TLS version 1.2 [TLS12] or higher for HTTP/2 over TLS.

13

Yes TLS1.2 but only with specific ciphers it seems to me and no TLS1.3 actually.

Also the same errors for serverside TLS as it is not the clientside only.

14

Added some further limitations after contact with F5 support.

15

Short update HTTP/2 with TLS1.3 only is supported by some F5 vodo cipher rules magic and they will fix it in 21.1 as to not have to use the Voodoo magic.

Other than that Bug ID 1196505 should be solved in 21.2.

We are getting at a working TLS1.3 with HTTP/2 and AWAF/ASM.

16

Nikoolayy1​

Have you tested 21.1?