Messages

This may be a usable workaround for some.

Having registered an account with IPinfo, entered and saved the URL.

Create a new GeoIP alias. When saving this you should the IPinfo DB downloaded.

When I upgraded a firewall to 25.7.5 I also migrated from Maxmind to IPinfo. It was about 14 hours before I saw the IPinfo data downloaded and it has updated daily since. During the transition I did not notice any issues with GeoIP based rules (which is not to say that there were none).

Yesterday I migrated this firewall to newer hardware. All looked OK when I put it online, but there was no GeoIP data. This lead to the GeoIP rules not being applied and as a result I rolled back to the old hardware.

As noted it would be useful to be able to request a download of the data.

If you map the instruction in the original Draytek link (https://www.draytek.co.uk/support/guides/kb-isp-talktalk#vigor-vdsl2-modems) across to the fields given in section 2 of the device manual https://www.draytek.com/assets/online_manuals/pdf/DrayTek_UG_Vigor167_V1.4.pdf

I think you will be able to do what you are looking for.

Where a picture has been configured, would you consider adding the ability to display it on the Login screen?

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.