Messages

Oh - sorry and thanks for the hint (those who can read have a clear advantage aka. wlkikiV)

strange - our CE nodes are not registering the new 26.1 as installable.

Code Select Expand

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 25.7.11_2 (amd64) at Thu Jan 29 09:09:19 CET 2026
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ........ done
Processing entries: .......... done
OPNsense repository update completed. 930 packages processed.
All repositories are up to date.
Checking for upgrades (76 candidates): .......... done
Processing candidates (76 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***


Code Select Expand

# cat /tmp/pkg_upgrade.json
{
    "api_version":"2",
    "connection":"ok",
    "downgrade_packages":[],
    "download_size":"",
    "last_check":"Thu Jan 29 09:25:14 CET 2026",
    "needs_reboot":"0",
    "new_packages":[],
    "os_version":"FreeBSD 14.3-RELEASE-p7",
    "product_id":"opnsense",
    "product_target":"opnsense",
    "product_version":"25.7.11_2",
    "product_abi":"25.7",
    "reinstall_packages":[],
    "remove_packages":[],
    "repository":"ok",
    "upgrade_major_message":"",
    "upgrade_major_version":"",
    "upgrade_needs_reboot":"0",
    "upgrade_packages":[],
    "upgrade_sets":[]
}

yesterday the changelog had a wrong date (2025 instead of 2026)
today this is fixed

Code Select Expand

# /usr/local/opnsense/scripts/firmware/changelog.sh list | grep '\"26\.1\"'
{"series":"26.1","version":"26.1","date":"January 28, 2026"}
but maybe this has been cached somewhere?

https://forum.opnsense.org/index.php?topic=45606.msg234376#msg234376

with this we can continue to use our old workflow, creating users from LDAP/AD for OpenVPN.

but in fact it just creates the users from LDAP as users in opnsense as Cedrik wrote, so there might be a problem like you create them, @itngo

... OpenVPN configs will be deprecated will there be a migration tool or script to move those configs to the new Instances section?

I think many will be affected (yes, /me too) - maybe a community driven migration tool slurping the xml from the legacy cfg, digesting it and injecting the result into the right place in the config.xml would be great ...

Hello boku

In general:

 * with SSL/TLS the cert subject name or a alt name should match the DNS hostname / IP that is used in the client für connecting to the service
   for example in your first openssl s_client session you target mail.beuthen.net and the cert CN is for dms.beuthen.net - here you depend on the negligence of your client while checking the ssl cert: some might work with some special config, other not.

 * I am not familiar with caddy, but in general all these solutions cook with the same water in different pots:
    1. you can route the complete traffic direct to the target server, using the original encryption (e2e). Here the proxy sees only the encrypted packages and is agnostic of the content.
    2. you can terminate the ssl encryption on the proxy. so the client communicates with the proxy encrypted and here the traffic is decrypted. the proxy himself can pass the traffic to the target server unencrypted or can re-encrypt it. But the second step is not transparent to the client, he just sees the proxy.

It seems you want to use the re-encrypted version:
client -> proxy using TLS -> proxy uses SNI in order to decided where to route the traffic and in order to decide what cert to use (this is my understanding of SNI) -> proxy uses TLS to the original server (here the SSL settings must accept the cert from the server! and the proxy must resolve the DNS name of the target server to the right IP [dms.beuthen.net] - /me generally prefers using IPs here, but this is just my taste)

maybe this helps a little bit ... and sniffing the traffic on the proxy might help to ...

regards and good luck

first: I never used IMAPs w/ ALPN, so all below are assumptions. I just know ALPN in combination w/ HTTP(1.2/2)

hm ... I think you mix up things here ... imaps and https are different protocols

Code Select Expand

mode tcp in your backend cfg. is OK for this.

you should use openssl instead of curl for testing

Code Select Expand

openssl s_client -connect IPorDNS:993
openssl will log information about ALPN too, so you should first run a check against the original server ant d then against haproxy front

might be discreetly oversized for that task, but cert management (incl. configuring the reference to the cert to use for the Web GUI) is implemented in the ansible role for opnsense
https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense

another method could be using the API (https://docs.opnsense.org/development/api/core/trust.html) for uploading new certs, but I am not sure if there is a way to configuring the reference to the cert to use for the Web GUI via the API

for whomever may be interested ... we implemented the ldap sync in our ansible role vor opnsense

https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense/wiki/ldapsync

maybe this can be of some help for someone, otherwise pls just ignore it

Hello Franco

Well, indeed someone else might be missing it too.

I assume it will be available in the repo with the next release?

So thank you for adding it, and manual install is no problem in our case, as the playbook includes a task for this.
In my case I have already merged a PR that runs the script in question in a venv, so I can wait ...

Thank you for your support and explanations

Greetings
Klaus

Hello Franco.

Thank you for your reply and explanation.

Just to be clear: what scripts are we talking about? Official Python scripts found somewhere (with a Link just for reference) or custom scripts you've written yourself?

With my head down, I have to admit that rather the last is the case ...
https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense-checkmk/blob/main/files/firmware_status.py


So I will refactor that in order to use a venv (as Patrick suggested in #2)

Since 25.1.4 (https://forum.opnsense.org/index.php?msg=233320) the updated installation is missing py311-setuptools.
The package is not available in the repository.
As some monitoring scripts we use rely on this, wee need a fix for this.
Is this a error that will be fixed soon or will the setuptools package be gone for ever?

Thank you for any hints.

https://docs.opnsense.org/manual/firewall.html#processing-order
And the "quick" setting might be important here ...

... I will push to Github and you can take a look.

Great! Always interested and curious

There is a new feature in OPNsense that allows the importer to find CDs, and this fits perfectly.

Yes, I have followed the thread and seen the new feature with interest too ... The ideal for me would be a similar process like we do for linux since ages: build a customized preseeded cd image that will bring up the device with a working basic configuration and pass it over to the config management tool in use for finishing ...

For WireGuard, because it is a plugin, there needs to be a triggering event for the packages for the plugin to be installed.

Thanks for the hint, but I am aware of this ...
Using ansible we install packages and plugins too (https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense-plugpack), but maybe something went wrong in the order ...
The trick with the update process sounds quite interesting ... will notice this, thanks.

Thanks for the feedback and looking forward for your github repo..

Sounds interesting ...
btw. the ansible playbook I linked surely can be used to create a initial config:
https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense-playbook/blob/main/firewalls.yml#L24:L31
and we use it right this way: initial deploy and continuous maintenance based on the same tool and configuration  ... but that is another story, don't mind ...

Is the wireguard cfg you generate working if you apply it on a virgin install?

In the env where we use the generated cfg from scratch we use IPSec VPNs, and these work out of the box: (generate cfg, install opnsense, copy generated config.xml in place, reboot, works)
Just as a test  I tried once a device with additional wireguard config from scratch, but no wg instance was started ... as it is not our prod env and not the main problem at the moment, I did not dive deeper into it. (was at least more then a year ago, maybe the updates since then changed behavior ...)
Just interested if your approach creates a working wg config or the approach of just injecting a valid wg config in xml format is not sufficient ...

So some notes on the deploy experience would be appreciated ...

off topic, as it is not a jupyter Notebook.
But the ansible playbook from https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense uses a (fetched) config.xml and ensures some settings based on configurations made in yaml files  before provisioning them back to the device ...
So if you skip the config.xml fetch and push step, you have the same effect ... validating could be surely be implemented if someone is willing to contribute this ...