Topics

Can someone please provide insight into what changed in the upgraded acme.sh package, now v3.1.1_1..?

I noticed the dnsapi/dns_opnsense.sh fixes (commit d76f4b2) that were merged into master 4 days ago, were not included.

Any idea when those fixes might merge here?

cc: @franco

Looking at BIND config, the plugin looks to be broken on zone configuration. The Commands section used to have a stethoscope button , delete, etc. but now only has edit, clone and an ellipsis with a "Check & preview" tooltip. When clicked, the checks all fail, as does clicking "Show zone content", which suggests "Empty response from the backend. Please check logs."

I've also noticed that new ACLs are not immediately available to the General config tab.

Following upgrade to 25.7, filter logs on this OPNsense box increased from 35MiB daily to 750MiB daily, mostly DNS entries. I've had to delete filter logs to avoid the disk filling up. This is what led me to discover the above. There does appear to be a Brazil-based DNS Amplification Attack that has been underway for several days, so all of this might be coincidental, but I would like to eliminate configuration as an issue. Are there any good block lists for these types of attacks?

Another small regression, per GitHub issue #6516

The remote IP address is missing from the OpenVPN Dashboard Widget.

Note: I can only speak for client connections.

Following up from the previous topic:

The Dashboard Widget now only displays the gateway (remote server) IP address. The VIP is no longer shown.

The Connection Status page is missing the CN, Real Address (is this the gateway address?) and both Bytes Sent and Bytes Received.

I guess something changed between commit 13d77cc and the 23.1.5 release. Maybe due to changes for local server instances / connections..?

EDIT: Set to [SOLVED]

I can see the hotfix package on the mirror.dns-root.de mirror, but checking for updates does not prompt to upgrade.

From what I can tell, my auto update occurred right before the hotfix announcement.

I ended up running the following instead:

Code Select Expand

opnsense-patch 637bc31
opnsense-patch 4bc36a4
opnsense-patch e2dada5
opnsense-patch 3586e70

...and then rebooting.

Is that expected behaviour, i.e. for the hotfix to not be picked up?

Hi everyone,

Is it just me, or does anyone else have an empty OpenVPN dashboard widget?

Maybe a regression due to: openvpn: add ovpn_status.py script and configd action to fetch connected clients...?

Was wondering if anyone had setup OPNsense with a single leg on LAN only. If so, any gotchas...?

I was thinking it might become necessary to spin up FreeRADIUS as a temporary PoC to get some answers for this topic.

Just wanted to know if it was possible...  :-\

TIA,
Ben

A regression in handling the importation of intermediate CA certificates led to a general discussion regarding the importation of such certificates into the OPNsense trusted store.

The topic can be found here.

Given the discussion had thoroughly hijacked that topic, I thought it best to continue here...

Credit to Fright for continuing the conversation over there (and hopefully here too).

I think it remains unresolved as to if, when and how third-party or external intermediate CA certificates should be installed (at System: Trust).

For completeness, I note that it appears the internal intermediate CA (when established) cannot issue internal certificates.

To that end:

It is my understanding that it remains best practice to install intermediate CA certificates that form part of a certificate chain to internal services. Just to be clear, I'm not suggesting that intermediate CA certs should be imported for say external websites.

These certificates should normally form part of the Certificates message but in my experience that isn't always implemented. Courtesy of Fright's previous postings, the pertinent part of the relevant RFC is here for your reading pleasure.

I had suggested that any Intermediate CA should be imported into System: Trust: Certificates (marked as a CA) and the corresponding root CA to System: Trust: Authorities. I only said this because I presume a CA listed under Authorities cannot be revoked... I am not convinced this is the case. I have not been able to test whether a Root CA CRL could revoke an intermediate CA certificate imported into System: Trust: Authorities. I would normally assume this to be the expected behaviour.

Furthermore, after attempting to do this I realised it was not an appropriate solution as the private key also must be imported.

If I am not mistaken, it is noteworthy, that the change in default behaviour was prompted by the recent Let's Encrypt saga. It is worth looking at the discussions on GitHub for issues 5257 and 2554. It gives good insight into the mitigation employed and kulikov-a (which I presume is you Fright) explains the issues well.

I would like to continue a discussion about what should constitute best practice in the use of intermediate CA certificates. I expect the discussion will also include the importation of both Root and Intermediate CA CRLs. Perhaps this discussion will identify and / or resolve any necessary improvements in this space.

Please join in.

Hi All,

I noticed upon release of 21.7.2 that the Australian mirror (at mirror.as24220.net) had not updated from 21.7.1. IIRC, it was the same day the 21.7.2_1 hotfix was released. I had thought that perhaps delayed propagation of the patch might be the cause so I left it alone. I run a daily cron job to check and apply any updates so I presumed it would update in due course.

However, when I checked yesterday, I noticed I was still stuck on 21.7.1.  :o

Upon investigation it became evident that the AU mirror was offline. I changed to Amsterdam and it updated without issue.

I suspect this is the root cause of the problem here too.

Is someone able to check in with the maintainer? I noticed fichtner sorted it once before as detailed here.

I guess this highlights a potential security issue if one is not performing regular audits.  :-[

This could be dealt with programmatically, e.g. sending an email alert if a mirror is found to be down, providing for configuration of a secondary mirror for use on primary mirror failure, updating mirror statistics and alerting mirror maintainers, etc.

I would look into this myself, but find myself short of time at the moment. I also don't have access to back end systems and channels which would be necessary for some of the above.

Thanks,
Ben