Messages

Good question, the CA I had created for the OpenVPN usage did not had dots (.) or underscore (_) in any of the fields in the subject.

The Issuer was like this:
C = Switzerland, ST = Zurich, L = Zurich, O = Company Ltd, CN = Company Client VPN CA - G1

- Do you may have umlauts (ä, ö, ü or anything else non-7bit-ASCII) in any part of the certificate Subject? If yes, change and just use 7-bit ASCII.
- Is the validity of the Issuer Root CA longer (starts before and ends after) then of the individual user certificates?
- Is the 'Certificate Type' set to 'User Certificate' for the VPN user certificate?

No, not quite. You mention that you created an user 'vpnadmintest', but the output from your certificates clearly states 'CN = vpn_jensl'.

But there is something else which is more concerning and could be the problem of the whole issue you have, look closely at this part:
'O = firm,, CN ='
I wonder from where this additional ',' (comma) just after 'firm' is from? But I guess that you manually replaces the content for ST, L, and O. But if for any reason there may be a comma in one of the original entries, I guess this may cause an issue with parsing out the CN entry.

Please check the details of the certificate itself. In System / Trust / Certificates you get the list of all certificates. Click the (i) button on the right and the certificate content will be shown as text.

Look for the line starting with "Subject:" an then what the 'CN = ' part is showing. If this is not 'vpnadmintest' and something else, but it is what you have entered as Common Name into the certificate.

Where exactly is that "IPv4 gateway rules" option you refer to, I can't seem to find it anywhere.

It may be that this option is not available when using PPPoE. In my case it is an Ethernet WAN with static IP address and this setting is in the
"Static IPv4 configuration" section.

But this was only one idea, the probably more working idea is the second one, with only one Gateway for both PPPoE interfaces (uplinks) and doing the outbound routing through the manual NAT rules.

Hope this helps and may work.

I have now created the issue 9142 for this.

Did you do the "Run an audit" for Health in Systems / Firmware / Status?

If this is fine, then try this:
Login in trough ssh or console, in the menu chose "8) Shell" and then run:
opnsense-bootstrap

This will reinstall the whole systems (but keep your config). If you had plugins installed, you need to re-install them afterwards as well (Systems / Firmware / Plugins). As the config is still there, you see which are missing and just click the (re-)install button on the right side.

As a possible explanation why such things can happen:
I have seen cases where during update it may have failed to install some packets properly, mostly because of not enough memory available. I have two systems running with very low memory (way below the recommendation of 2 GB), so I have seen such things, but I am able to temporary increase the memory on this virtual machines.

Thinking it through again, I guess you should be fine with creating only one Gateway, as it really is only one. But I am not sure if you will be able to select the same Gateway for both your WAN (aka PPPoE) interfaces. But I guess that should work.
With checking some settings on my end, I have discovered that in my dual WAN setup I have set "IPv4 gateway rules" to disabled in the WAN settings. It may be useful in your case as well, or not, you have to try.

With only one Gateway, you still will be able to create manual Outbound NAT rules, to work for your case. As you can setup NAT rules with the Interface, Source and NAT Address you should be able to route outbound traffic properly, e.g with something like this:

Interface	Source	NAT Address
PPPoE1	10.10.10.0/24	PPPoE1 address
PPPoE2	10.10.20.0/24	PPPoE2 address
PPPoE2	127.0.0.0/8	Interface address

So now traffic out of LAN1 (10.10.10.0/24) will use the IP address of your standard PPPoE connection, and out of LAN2 (10.10.20.0/24) will use the IP address of your static IP PPPoE connection. The 127.0.0.0/8 rule is so that the OPNsense itself is able to create outbound connections.
In this case I think it should work and you do not need to assign a Gateway in the firewall rules.
So you are using the manual NAT Outbound rules to decide which public / WAN IP address an internal networks will use.

I guess this should also work with Port Forward, in case you need this.

So then please create a bug report.

If you also want to play with other themes, you first need to install them through System / Firmware / Plugins. You may have to enable the "Show community plugins" on top right. To show only themes, filter for "theme". The one I am using is called "os-theme-cicada".

After installing it needs to be set it in Systems / Settings / General.

If the menu is not shown after the SSH login, this is clearly a sign that the system is in a broken state.

As already mention, I would try if you can fix it with running

Code Select Expand

opnsense-bootstrapin your ssh session (you need to be root).

Daft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.

It only takes a break (or a stuck pin, or some dirt) in pins 4, 5, 7 or 8 and the connection willl never go above 100Mbps.
Changing the cable would always be my first check.  A quick look in the two sockets with a torch would be my next quick check!

Yes, the 1 Gbit/s does need all 8 wires in the cable to be fine. In case your Ethernet cable may have a sharp bend (or had one in the past) one of the wires in it could be partially or fully broken, which will give you loose connection and so the auto negotiation does fail.

It could be an issue with the network driver, but I don't think that this minor OPNsense update has any NIC driver updates, as the underlying FreeBSD did not have even a minor update (I think).
If you did not touch the system or cable during the update / reboot to 25.7.2, then some thermal issue cause from the update (e.g. higher CPU / Network traffic) could have caused that an already damaged cable now broke completely.
At least I would also try with a different Ethernet cable, and also check that the sockets on both ends do not have any dust in it and still look fine.

As I see it, the only possible way is to add all TLDs into the "Wildcard Domains", a full list is at https://newgtlds.icann.org/en/program-status/delegated-strings

But according to the help text, this may allow sites running on the TLD itself to still be accessible.

Not sure if you e.g. can create your own DNSBL and then use that.

I have never seen it like this, but I am using the cicada theme since a long time to have a dark mode. Is this with the new OPNsense own dark mode? I have only enabled it for a short time to see how it looks and switched back to cicada as I did like that better. But of course this is my personal opinion.

Maybe creating an issue at https://github.com/opnsense/core/issues is the best way forward.

The nics in my appliance are two intel i210 nics, which until now never have gave my any problems. Can this please be fixed so that i can use full bandwith of my internet connection again?

I would try to unplug and then plug in the network cable from both your OPNsense and the cable modem. If that does not fix it, then try with fully powering off (may need to unplug the power cable) both devices. If the SuperMicro does have an BMC module, wait for one or two minutes until it is fully off (NIC LED may be an indicator).

Hopefully this helps and the NIC will be able again to properly do autosense and sync with 100 Mbit/s.

I have never tested such own blocks so far. It depends what exactly Unbound does return to a resolving client. In DNS even negative answers have a TTL, so clients will also cache this and not re-request it for some time. On unix-based systems you may be able to check with 'dig duckduckgo.com' (in below output the current TTL is 200 seconds):

fabian@flashback:~/ % dig duckduckgo.com       

; <<>> DiG 9.10.6 <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54015
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;duckduckgo.com.         IN   A

;; ANSWER SECTION:
duckduckgo.com.      200   IN   A   40.114.177.156

;; Query time: 66 msec
;; SERVER: 2001:xxxx:xxxx:1::2#53(2001:xxxx:xxxx:1::2)
;; WHEN: Fri Aug 22 17:16:10 CEST 2025
;; MSG SIZE  rcvd: 59

Two things you can do, or just wait until TTLs have expired:

1) In Unbound settings in General enable the "Flush DNS Cache during reload" and then restart unbound service

2) Figure out how to flush local DNS cache on your client system, some system do this e.g. when the LAN cable is unplugged and plugged in again (or corresponding the Wi-Fi is turned off and on again).

Does the ssh login still show the menu? If yes, you can choose

12) Update from console

And hope that it does run trough.

If the menu does not show up any more on login, maybe try with this in the ssh session:
opnsense-bootstrap

If that also fails, use the installer DVD/USB and you may even be able to load your last config from the local disk (you do need the name of it, e.g. da0, ad0 or such) to run the live system and from there go with a fresh install.