OPNsense haproxy SSL_TLS_SNI header

[DieThiFl]

We're using OPNsense(s) running version 25.1 with haproxy in front of several VMs with a lot of webservers having a lot of different domain-/hostnames.
After the last apache CVE patch about 3 weeks ago (at least on ubuntu systems) we have the problem with the "Error 421 Misdirected Request" message.
The are a lot of posts describing how to solve this on plesk or similar systems or native nginx proxies. But what about haproxy?
The problem is the missing "SSL_TLS_SNI" header in the requests, haproxy is forwarding to the matching target webserver.
Does anyone have the same problem and maybe sovled this problem already?

We tried to set up an additional an complrte new firewall with OPNsense version 25.7, but this does not solve this problem so far.
I can't find any haproxy settings in either OPNsense versions to fix the problem.

Thanks in advance,
DT

[MoonbeamFrame]

Could it be related to a change that I saw announced on Debian Bullseye recently?

 

apache2 (2.4.65-1~deb11u1) bullseye-security; urgency=medium

  Following the resolution of CVE-2025-23048,
  some SSL-enabled websites may begin encountering
  the error (AH02032):
  .
    Misdirected Request:
    The client needs a new connection for this request as the
    requested host name does not match the Server Name Indication
    (SNI) in use for this connection.
  .
  This behavior is particularly noticeable with AWS Application
  Load Balancers. Although they support intelligent SNI handling,
  they do not (as of this writing) relay SNI data to the target
  server, resulting in failed connections when hostnames don't align.
  .
  Without an SNI provided by the client, there is nothing httpd
  can do to determine which vhost/configuration should be
  used to provide the correct certificate (and TLS authentication
  eventually) whenever multiple vhosts listen on the same IP:port.
  .
  That's because reading the HTTP Host header necessarily has to
  happen after the TLS handshake/auth/decryption (and later
  renegotiation is not an option with TLSv1.3).
  .
  So those connections fall back to the first vhost declared on
  the IP:port for the TLS handshake part, and if the request
  Host header finally matches a different vhost with a different
  TLS configuration it's rejected with AH02032.
  .
  Before 2.4.64 the check was not accurate and would allow that,
  with security implications.
  .
  As a workaround, you may (after a risk analysis) generate a
  wildcard certificate. If you're managing multiple domains,
  consolidate them into a single certificate by including each
  wildcard domain as an alias. Then, update the Apache configuration
  to reference this unified certificate.
  .
  Another possible workaround is to configure each virtual host to
  listen on a separate port. This approach avoids SNI-related issues
  by ensuring that each vhost is uniquely addressed through its own
  connection endpoint, thereby allowing distinct TLS configurations
  without ambiguity.
  .
  This error may also stem from a misconfigured HAProxy setup.
  In such cases, enabling dynamic SNI handling on HAProxy might be
  necessary to ensure that the correct hostname is passed through
  during the TLS handshake. After risk analysis, it could be done
  by using "sni req.hdr(Host)" directive.

 -- Bastien Roucariès <rouca@debian.org>  Fri, 25 Jul 2025 20:33:38 +0200