Messages

I had a problem with an Acme certificate about 3 years ago.  There's a post here HERE about the corruption that I found in my config.xml file.
I've just had a look at my current config.xml to see if it lines up that the 3-year old version.  There's a slight change to the certificate block.  They now look like :

Code Select Expand

<?xml version="1.0"?>
<opnsense>
  <version>11.2</version>
  .
  <cert uuid="3d19c8be-0d2c-4267-bfd2-f322c88a6dcf">
    <refid>a1b2c3d4e5f6</refid>
    <descr>Text Description</descr>
    <caref>a1b2c3d4e5f60</caref>
    <crt>[Very long continuous string of the public key of this certificate]</crt>
    <csr/>
    <prv>[Very long continuous string of the private key of this certificate]</prv>
  </cert>
Otherwise, I'm pretty sure the rest of that post is still accurate.

It's clearly important that the certificate that the web server is using is the new one that the Acme client has received.  I never found why my config.xml didn't get updated properly.

HTH (apologies if this isn't your problem)

PeterF

[Flush (full) local configuration history]

I do feel that the "Flush (full) local configuration history" option should be off by default, though. I would not normally expect a restore operation to destroy the history that would allow me to undo that restore.

+1 Thank you for highlighting this.  I hadn't particularly noticed this option - perhaps it's been there a long while (for ever?).  Fortunately, I haven't had to do a restore very often - more recently it's been rebuilds after disk death.

I do try & rememeber after a rebuild however, to reinstall my own customisations, one of which is to do a daily backup to a local machine using rsync.  I use the backup option in rsync which means that any deleted files are then saved to another directory.  The downside of that is the rsync backup directory just keeps growing and once every couple of years I have to do some manual housework and delete the old junk.

I was seriously tempted by the Nextcloud (NC) backup option (since I also run a private NC instance).  However, since I currently refuse to expose my NC to the internet, it has to run with a self-signed certificate and AFAICS the OPNsense NC plugin won't run with a self-signed certificate, so I'm stuck with my rsync backup.

One of my other customisations is a script which can change standard OPNsense files.  I've just added an entry to the config file that it uses to delete this "automatic" tick that appears against Flush... in the restore option.  The script runs twice a day and just makes the tweaks that I want if it detects that they need doing (after an update for example).  The downside of this is that these changed files get flagged during a health check.  Since my script saves the original file, I can always put them back in place to fully pass a health check.

PeterF

I could solve my issue by resetting the ACME Client like fraenki described on github.
https://github.com/opnsense/plugins/issues/3154

OpnSense -> Services -> ACME Client -> Settings -> Reset ACME Client

After that I could successfuly automaticaly renew all certs.

Thanks all  :)

Still 2026 ;-)
This post was very helpful to me.  I'd clearly forgotten about doing the reset when I rebuilt a few months ago.

PeterF

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!

[/usr/local/etc/opnsense-beep.d]

Attached, I've created the Pac-man, Ms. Pac-man, AC/DC's Thunderstruck, and Super Mario Bros. Victory tunes.

Drop 'em in the /usr/local/etc/opnsense-beep.d directory and, if you're like me, you can rename the start and stop beep tunes to these to have OPNSense play a nifty tune instead of the usual ones.

I've taken the liberty of putting all your fun beeps into a single tar archive to make it easier to sample all your work.
Many thanks for publishing these, I've changed my "start" beep already.

PeterF

Just checked my /root dir, and, apart from the dot files, everything there is stuff I've created.
That's why I use it, because the system doesn't.

[Many thanks]

Upgrade via the GUI was flawless on an old Dell 9020 SFF with quad Intel I350 Gb NW card. Before the update, Intel CPU microcode updates were not installed, neither were legacy support for IPsec and OpenVPN.  ACME, Squid & Nginx all upgraded ok.  Had to manually install the patch (61d289c) to get the dynamic dns widget to display correctly.
Many thanks for all the hard work that goes into making this a well-supported system.

PeterF

Hi

I've been running V24.1.9_3 since 20-Jun & everything appeared to be fine on the surface.  Today, since 24.1.10 became available, I cleaned my glasses properly & looked at the dashboard and realised that I had no IPV6 addresses.  (I do have a public V4 (and no CGNAT) which explains  why I (we) hadn't noticed that anything was awry before.

I rebooted the FW and noted that IPV6 was back ok.  I then set to, writing a logging script to check how long it took to fail.  My public V6 address had gone before I'd finished writing the script  ::) .   So I finished the script, rebooted again, and ran the logging script.  It took precisely 10 minutes to lose the V6 address again (sounds like a 600 sec lease to me).

I then did a backup of the config file, and tried to do the update to 24.1.10_1.  That didn't work.  I'm guessing that part of the system was trying to do the upgrade using IPV6, which had silently gone away.

So I rebooted again, and started the update to 24.1.10_1 before I lost my V6 public address.  The update appeared to go ok.  When it had finished, I did a manual reboot (but not a filter reload - because I wasn't sure what that was referring to) and the system has now been up for just over an hour.  My IPV6 logging script shows that my V6 address hasn't gone awol.

So 24.1.10_1 seems to have fixed whatever was wrong in 24.1.9_3 for me, at least.

I do have another live system, also running 24.1.9_3, but that system has a fixed IPV6 public address, but, unsurprisingly, that system shows absolutely no problem.

HTH

PeterF

Hi

I noticed that your traffic graph is displaying (only) Ipsec traffic.  If you want to look at WAN or LAN traffic, then you need to select those using the drop-down list (arrow to the right of "Traffic" on the tab).

Regards,

PeterF

[dyn_dns widget]

Hi

I encountered this problem earlier toay - with just the top & left side of the Webgui page visible.  I looked at the page source and at the end, there was a crash report indicting dyn_dns widget. 

Code Select Expand

Fatal error: Uncaught Error: Failed opening required 'plugins.inc.d/dyndns.inc' (include_path='/usr/local/etc/inc:/usr/local/www:/usr/local/opnsense/mvc:/usr/local/opnsense/contrib:/usr/local/share/pear:/usr/local/share') in /usr/local/www/widgets/widgets/dyn_dns_status.widget.php:34
Stack trace:
#0 /usr/local/www/index.php(413): include()
#1 {main}
  thrown in /usr/local/www/widgets/widgets/dyn_dns_status.widget.php on line 34


So (in a terminal window) I removed:

Code Select Expand

rm /usr/local/www/widgets/widgets/dyn_dns_status.widget.php

and

rm /usr/local/www/widgets/include/dyn_dns_status.inc
and then refreshed the page.  Having got the webgui back again, I was able to go & finish the cleanup in SYTEM : FIRMWARE...

HTH someone. 
Pity I hadn't found this page earlier - I could have prevented the problem  >:(

PeterF

Hi

Apologies for the delay (I've only just seen your post)...
I have been successfully using Toob (900Mb up & down - fibre) since December 2022.  It's my only wan connection from my OPNsense firewall.
IPV4 configuration was easy (DHCP).  The biggest challenge was finding out what Toob expected for IPV6.  Their help desk was completely unhelpful, so it was a matter of deduction from the configuration of their supplied router.  I got there in the end.
One gets a /64 (via DHCPv6) for the wan connection, and a /56 for one own consumption.

PeterF

Ok...got a fix, but no idea why/how it broke in the first place.

Glad it's sorted for you.  I'm going to watch my certificate the next time LE does an update and see what happens.

I think the protocol now is for you to insert a [SOLVED] at the beginning of your post title, if you're happy that it is.

Good luck!

PeterF

[old]

Hi DenverTech

I had a similar situation in the middle of March (2023) - I was running V23.1_6 at the time.  Whilst running V23.1_6 my Acme.sh had run successfully because a certificate update was needed.  I didn't bother looking at the certificate details, until I noticed that my browsers (I tried different browsers on different machines too) were all telling me that there was a certificate problem.  I looked at the certificate and sure enough it had expired.  I spent a few hours digging to try and understand how certificates are stored and referenced in OPNsense.  What follows is a summary of how certificates are stored, what caused the problem in my system, and how I fixed it.

All certiificates are stored in the config file ( /conf/config.xml ) in a structure that looks like the box below.  "<cert>" is at level 2 (with "<opnsense>" at level 1 (top)).  There is a separate "<cert>" section for each certificate.  The "<refid>" item is unique for every certificate, and is used to select a required certificate.

Code Select Expand


<?xml version="1.0"?>
<opnsense>
  <version>11.2</version>
  .
  <cert>
    <refid>a1b2c3d4e5f6</refid>
    <descr>Text Description</desc>
    <crt>[Very long continuous string of the public key of this certificate]</crt>
    <prv>[Very long continuous string of the private key of this certificate]</prv>
  </cert>


Now in another level 2 section denoted by "<system>", there exists a level 3 section denoted by "<webgui>".  See the next box for its structure:

Code Select Expand


<?xml version="1.0"?>
<opnsense>
  <version>11.2</version>
  .
  <cert>
    .
  </cert>
  .
  <system>
    .
    <webgui>
      <protocol>https</protocol>
      <ssl-certref>6045008dd0e08</ssl-certref>
      <port>8443</port>
      <ssl-ciphers/>
      <interfaces/>
      <compression>5</compression>
      .
      .
    <webgui>
    .
  </system>




The item "<ssl-certref>" contains the 12-digit identifier for the certificate that is to be used for the web server. 

In my system which was still serving the out-of-date certificate, the identifier (pointer) contained in the "<ssl-certref>" parameter was actually the id for the old certificate, not the new certificate that had been acquired by acme.sh.  That explained why the certificate being served by the web server, was out of date.

Fixing the problem

• I made a backup copy of the config.xml file
• I located the new acme.sh acquired certificate in its <cert>..</cert> block and noted its refid
• I edited the config file and updated the certificate reference in the "<ssl-certref>" section with the correct id from step 2
• Rebooted the system

That fixed the problem for me.  What I didn't do was locate the code that updates the <webgui> section after acme.sh has run and try to come up with an hypothesis as to why it wasn't updated correctly when acme.sh ran successfully.
I'll keep an eye on it the next time acme.ssh runs to see if it happens again.

An Aside

Having fixed the certificate pointer, I went and looked at the certificates from the GUI (System -> Trust -> Certificates ).
I then noticed that the entry for the old (out-of-date) certificate for (ACME Client) now had a little waste bin icon at the end of the line, indicating that it could be deleted.  When I had started my investigation I had noted that there was no waste bin icon for the old certificate.

HTH with your problem

PeterF

Hi

Have you checked the dates on both ends?
BTW, I use FreeOTP (Ver 2.0.1 (42)) on Android - works well & appears stable.

PeterF

[Then]

Hi all,

I am in the process of activating 2FA (TOTP) for all services that offer it. E.g. Github, our self hosted Gitlab, Hetzner, Paypal, ... you name it.

For all of these services the login procedure is the same:

1. Prompt for username and password. Sometimes first only username, <ENTER>, then password <ENTER>.
2. Then I am asked for the 6 digit one time token.

This works great because I have been using password safe software for years and the username and password get filled in automatically. Then I have one more step to enter the OTP. Perfect.

With OPNsense it seems there is only one prompt for username and password and you are supposed to append (or prepend depending on configuration) your OTP to the static password.

How is this expected to work? The password is filled in by the password manager. Visible as a bunch of dots or stars. If I append the OTP in that same field my browser asks me if I want to update the saved password for that service every single time.

WTF? What is the idea behind this completely insane user interface? Unless I get one prompt for fixed username and password and then a second one for the OTP, 2FA on OPNsense is unusable. Every other service I have ever used with TOTP does this.

Kind regards,
Patrick

I concur with Patrick on this one - having to remember the password (because I can't use one from my password manager) and type it, and the OTP into the PW field is an absolute pain. 

Please could we have the separate OTP field as a New Year present  ;)

Thanks for all the hard word.

Seasons greetings to all

PeterF