Messages

Example

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

Thanking all of you that have responded.

My interim solution has been to terminate the copper from both the ONT's onto one of my Unifi switches.
Then trunk the traffic to the OPNsense box via SFP+/DAC.

What about the Official HW? DEC

I did look, but there do not appear to be any with 10Gbit/s copper ports. So the only option would be 4 x SFP+

Copper SFP+ modules run very hot.

XGS-PON is becoming available from my service providers and I have started to look for hardware to facilitate migration to these services.

While I can find hardware with combinations of 2.5Gbit/s copper with SPF+, I am yet to find much in the SOHO market with 10Gbit/s copper with SPF+.

Does anyone have any recommendations for hardware that will run OPNsense?

I prefer dark mode and I find the blue is easier to read than the orange.

As noted a little more contrast for the blue would help.

[2025-03-14T16:31:26 Error monit /usr/local/etc/monitrc:12: syntax error 'L@|y=']

I was configuring Monit on a remote firewall and when it would not start found a log error:

2025-03-14T16:31:26 Error monit /usr/local/etc/monitrc:12: syntax error 'L@|y='

The text in question was from the Mail Server Password field in General settings.

So your ISP is PlusNet (part of the BT group as I was last aware).

You look to have a gateway running. Some DHCP errors. Maybe sort those out next.

Then it might be helpful if you try a state what problem you are trying to solve.

Who is your ISP?
Is PPPoE configured and connected?
Do you need to use a VLAN for your ISP?

Not trying to be obtuse, just my train of thought went in another direction.

Plugins

os-apcupsd
os-cpu-microcode-intel
os-nextcloud-backup
os-squid
os-tayga
os-theme-vicuna
os-wol

HP ProLiant MicroServer Gen10 Plus

I posted just after this had occurred.

On reflection I wondered if this is related to earlier reports where when a restart had been requested the GUI displayed the Dashboard followed by a delay before the restart was executed.

[The system is powering off now]

I've just tried to restart a firewall several times from the GUI. It returned to the GUI sometime later without restarting.

I then tried to power it off. The GUI remained at The system is powering off now but never powered off.

Watching the console via the iLO interface no activity was logged during this process.

I've not seen any problems with my  Android devices, which include a Nexus 7 (2013) a Galaxy S6e and current models.

These are all on IPv4 networks.

I've done a couple of firewalls.

They did both reboot, but not before showing the dashboard with 24.7.5.

I watched the second one via it's iLO console an could see a delay between the dashboard refresh and it starting to stop services for the reboot.

Try using the fullchain.pem instead of the cert.pem