Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Gromhelm

#1
Ok, thanks! I tried today this morning with the same mirror, and it worked immediately. So this was a first for me. Good to know that this mirror feature exists!
#2
I tried to update today to 25.7.10 and it downloads forever at "Fetching base-25.7.10-amd64.txz". The update then fails after 10 Minutes with "failed, signature invalid"

Here is the full log:
***GOT REQUEST TO UPDATE***
Currently running OPNsense 25.7.9_7 (amd64) at Fri Dec 19 20:16:28 CET 2025
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (85 candidates): .......... done
Processing candidates (85 candidates): .. done
The following 16 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
    dpinger: 3.3 -> 3.4
    gettext-runtime: 0.23.1 -> 0.26
    glib: 2.84.1_3,2 -> 2.84.4,2
    libgpg-error: 1.56 -> 1.58
    libucl: 0.9.2_2 -> 0.9.3
    nss: 3.118.1 -> 3.119.1
    opnsense: 25.7.9_7 -> 25.7.10
    opnsense-update: 25.7.8 -> 25.7.10
    php83-phpseclib: 3.0.47 -> 3.0.48
    py311-anyio: 4.11.0 -> 4.12.0
    py311-certifi: 2025.10.5 -> 2025.11.12
    py311-dns-lexicon: 3.21.1 -> 3.23.2
    py311-numpy: 1.26.4_10,1 -> 1.26.4_11,1
    py311-tzdata: 2025.2 -> 2025.3
    py311-urllib3: 2.5.0,1 -> 2.6.0,1
    socat: 1.8.0.3 -> 1.8.1.0

Number of packages to be upgraded: 16

22 MiB to be downloaded.
[1/16] Fetching py311-anyio-4.12.0.pkg: .......... done
[2/16] Fetching dpinger-3.4.pkg: . done
[3/16] Fetching opnsense-update-25.7.10.pkg: .... done
[4/16] Fetching py311-numpy-1.26.4_11,1.pkg: .......... done
[5/16] Fetching nss-3.119.1.pkg: .......... done
[6/16] Fetching py311-dns-lexicon-3.23.2.pkg: .......... done
[7/16] Fetching php83-phpseclib-3.0.48.pkg: .......... done
[8/16] Fetching py311-certifi-2025.11.12.pkg: .......... done
[9/16] Fetching py311-tzdata-2025.3.pkg: .......... done
[10/16] Fetching socat-1.8.1.0.pkg: .......... done
[11/16] Fetching libgpg-error-1.58.pkg: .......... done
[12/16] Fetching gettext-runtime-0.26.pkg: .......... done
[13/16] Fetching py311-urllib3-2.6.0,1.pkg: .......... done
[14/16] Fetching glib-2.84.4,2.pkg: .......... done
[15/16] Fetching libucl-0.9.3.pkg: ........ done
[16/16] Fetching opnsense-25.7.10.pkg: .......... done
Checking integrity... done (0 conflicting)
[1/16] Upgrading dpinger from 3.3 to 3.4...
[1/16] Extracting dpinger-3.4: .... done
[2/16] Upgrading gettext-runtime from 0.23.1 to 0.26...
[2/16] Extracting gettext-runtime-0.26: .......... done
[3/16] Upgrading glib from 2.84.1_3,2 to 2.84.4,2...
[3/16] Extracting glib-2.84.4,2: .......... done
[4/16] Upgrading libgpg-error from 1.56 to 1.58...
[4/16] Extracting libgpg-error-1.58: .......... done
[5/16] Upgrading libucl from 0.9.2_2 to 0.9.3...
[5/16] Extracting libucl-0.9.3: .......... done
[6/16] Upgrading nss from 3.118.1 to 3.119.1...
[6/16] Extracting nss-3.119.1: .......... done
[7/16] Upgrading opnsense-update from 25.7.8 to 25.7.10...
[7/16] Extracting opnsense-update-25.7.10: .......... done
[8/16] Upgrading php83-phpseclib from 3.0.47 to 3.0.48...
[8/16] Extracting php83-phpseclib-3.0.48: ......... done
[9/16] Upgrading py311-anyio from 4.11.0 to 4.12.0...
[9/16] Extracting py311-anyio-4.12.0: .......... done
[10/16] Upgrading py311-certifi from 2025.10.5 to 2025.11.12...
[10/16] Extracting py311-certifi-2025.11.12: .......... done
[11/16] Upgrading py311-dns-lexicon from 3.21.1 to 3.23.2...
[11/16] Extracting py311-dns-lexicon-3.23.2: .......... done
[12/16] Upgrading py311-numpy from 1.26.4_10,1 to 1.26.4_11,1...
[12/16] Extracting py311-numpy-1.26.4_11,1: .......... done
[13/16] Upgrading opnsense from 25.7.9_7 to 25.7.10...
[13/16] Extracting opnsense-25.7.10: .......... done
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.
>>> Invoking update script 'refresh.sh'
Flushing all caches...done.
Writing firmware settings: FreeBSD OPNsense
Writing trust files...done.
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Scanning /usr/local/share/certs for certificates...
certctl: No changes to trust store were made.
Writing trust bundles...done.
Configuring login behaviour...done.
Configuring cron...done.
Configuring system logging...done.
[14/16] Upgrading py311-tzdata from 2025.2 to 2025.3...
[14/16] Extracting py311-tzdata-2025.3: .......... done
[15/16] Upgrading py311-urllib3 from 2.5.0,1 to 2.6.0,1...
[15/16] Extracting py311-urllib3-2.6.0,1: .......... done
[16/16] Upgrading socat from 1.8.0.3 to 1.8.1.0...
[16/16] Extracting socat-1.8.1.0: ......... done
==> Running trigger: glib-schemas.ucl
Compiling glib schemas
No schema files found: doing nothing.
==> Running trigger: gio-modules.ucl
Generating GIO modules cache
=====
Message from opnsense-25.7.10:

--
Some will win, some will lose, some are born to sing the blues
=====
Message from py311-urllib3-2.6.0,1:

--
Since version 1.25 HTTPS connections are now verified by default which is done
via "cert_reqs = 'CERT_REQUIRED'".  While certificate verification can be
disabled via "cert_reqs = 'CERT_NONE'", it's highly recommended to leave it on.

Various consumers of net/py-urllib3 already have implemented routines that
either explicitly enable or disable HTTPS certificate verification (e.g. via
configuration settings, CLI arguments, etc.).

Yet it may happen that there are still some consumers which don't explicitly
enable/disable certificate verification for HTTPS connections which could then
lead to errors (as is often the case with self-signed certificates).

In case of an error one should try first to temporarily disable certificate
verification of the problematic urllib3 consumer to see if that approach will
remedy the issue.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
The following package files will be deleted:
    /var/cache/pkg/libucl-0.9.3.pkg
    /var/cache/pkg/py311-numpy-1.26.4_11,1~d5a615882f.pkg
    /var/cache/pkg/py311-dns-lexicon-3.23.2~cf3889e77e.pkg
    /var/cache/pkg/nss-3.119.1~4b1fda0aab.pkg
    /var/cache/pkg/py311-urllib3-2.6.0,1~c0b1f10e54.pkg
    /var/cache/pkg/glib-2.84.4,2.pkg
    /var/cache/pkg/py311-certifi-2025.11.12~215272b159.pkg
    /var/cache/pkg/dpinger-3.4~276601a0c0.pkg
    /var/cache/pkg/py311-dns-lexicon-3.23.2.pkg
    /var/cache/pkg/nss-3.119.1.pkg
    /var/cache/pkg/py311-urllib3-2.6.0,1.pkg
    /var/cache/pkg/py311-anyio-4.12.0.pkg
    /var/cache/pkg/py311-anyio-4.12.0~f3781d8bca.pkg
    /var/cache/pkg/libgpg-error-1.58~dc941ea303.pkg
    /var/cache/pkg/py311-certifi-2025.11.12.pkg
    /var/cache/pkg/opnsense-25.7.10~e8fe778b04.pkg
    /var/cache/pkg/opnsense-update-25.7.10~87bc1e1d0a.pkg
    /var/cache/pkg/libgpg-error-1.58.pkg
    /var/cache/pkg/glib-2.84.4,2~6b60e61d06.pkg
    /var/cache/pkg/opnsense-update-25.7.10.pkg
    /var/cache/pkg/gettext-runtime-0.26~dadd59a075.pkg
    /var/cache/pkg/php83-phpseclib-3.0.48~5bf8d63581.pkg
    /var/cache/pkg/php83-phpseclib-3.0.48.pkg
    /var/cache/pkg/opnsense-25.7.10.pkg
    /var/cache/pkg/dpinger-3.4.pkg
    /var/cache/pkg/libucl-0.9.3~417cf27395.pkg
    /var/cache/pkg/socat-1.8.1.0.pkg
    /var/cache/pkg/py311-tzdata-2025.3.pkg
    /var/cache/pkg/py311-tzdata-2025.3~fa615f73d6.pkg
    /var/cache/pkg/py311-numpy-1.26.4_11,1.pkg
    /var/cache/pkg/gettext-runtime-0.26.pkg
    /var/cache/pkg/socat-1.8.1.0~67390374ff.pkg
The cleanup will free 22 MiB
Deleting files: .......... done
Nothing to do.
Starting web GUI...done.
Fetching base-25.7.10-amd64.txz: ... failed, signature invalid
***DONE***

I did an health audit:
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 25.7.10 (amd64) at Fri Dec 19 20:36:08 CET 2025
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 25.7.8 is incorrect, expected: 25.7.10
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 25.7.8 is incorrect, expected: 25.7.10
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-acme-client 4.11
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 25.7.10 has 67 dependencies to check.
Checking packages: .................................................................... done
***DONE***

In update, I see that base and kernel are still listed as updateable. If I repeat the process, I get the same. I fear restarting the box now that it is in an unstable state.

There's enough space left:
root@router:~ # df -h
Filesystem                   Size    Used   Avail Capacity  Mounted on
zroot/ROOT/default           8.3G    1.4G    7.0G    17%    /
devfs                        1.0K      0B    1.0K     0%    /dev
zroot/tmp                    7.0G    1.2M    7.0G     0%    /tmp
zroot/var/crash              7.0G     88K    7.0G     0%    /var/crash
zroot/usr/ports              7.0G     88K    7.0G     0%    /usr/ports
zroot                        7.0G     88K    7.0G     0%    /zroot
zroot/var/audit              7.0G     88K    7.0G     0%    /var/audit
zroot/var/log                7.1G     94M    7.0G     1%    /var/log
zroot/var/mail               7.0G    112K    7.0G     0%    /var/mail
zroot/var/tmp                7.0G    100K    7.0G     0%    /var/tmp
zroot/usr/home               7.0G     88K    7.0G     0%    /usr/home
zroot/usr/src                7.0G     88K    7.0G     0%    /usr/src
devfs                        1.0K      0B    1.0K     0%    /var/dhcpd/dev
devfs                        1.0K      0B    1.0K     0%    /var/unbound/dev
/usr/local/lib/python3.11    8.3G    1.4G    7.0G    17%    /var/unbound/usr/local/lib/python3.11
/lib                         8.3G    1.4G    7.0G    17%    /var/unbound/lib

dmesg looks good, too. It is a little protectli box that has never caused problems before.
#3
Tested, works. Thank you!
#4
I tried `-1` in `keyingtries` to get the `%forever` in swanctl.conf with the current OPNsense production version, but the GUI tells me `-1` is not allowed.

Can anyone point me to the correct setup here for Site-to-Site IPSEC connections to keep trying after any WAN failure?
#5
Yes, my issue was rather that the use of FQDN did not work as PSK Identity. I had to put a user in front of it. Not sure if this is related to the other side, where I use pfSense and maybe the FQDN for PSK ID is first resolved to an IP and then send over, where the match fails. Anyway, with User Distinguished FQDN, this works now.

All seems to work now. Updated my blog post here:
https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/
#6
Doh, I just found out that the new IPSEC Implementation seems not to support FQDN anymore (like I am trying to do)

https://github.com/opnsense/core/issues/6781

> you mentioned your setup worked before this change, dynamic addresses weren't supported before 21.1.4 for the new connections.

After extensive testing today, it seems I am confirming it does not work having a dynamic IP attached to a FQDN/CNAME entry, the connections are failing with "no matching peer config found".

See also this comment: https://linuxnews.de/verschlimmbessertes-vpn-ein-wort-der-warnung-zu-opnsense-deciso/

The problem seems to be that using an dynDNS FQDN CNAME entry as `Local addresses` (e.g.  jashdejvmiuqlachhsqaxs.siteb.example.com), is not acceptable, as the other side sends an actual IP (41.41.41.41), for which the comparison fails.

If I compare the swanctl.conf form legacy to the new, I can see that in the legacy conf, the actual IP was written:
        local_addrs = 41.41.41.41
        remote_addrs = 31.31.31.31

whereas if I download the new swanctl.conf, I see the FQDN entry:
        local_addrs = jashdejvmiuqlachhsqaxs.siteb.example.com
        remote_addrs = 31.31.31.31

What I am observing here is that if a packet comes in addressed to 41.41.41.41, and the config is jashdejvmi..., even though that resolves to the same IP, the match seems to still fail because strongSwan has not resolved it to 41.41.41.41 and stored that value.

This behavior is mentioned in the GitHub issue #6781. Resolving and using FQDNs in "Local addresses" can cause peer mismatches unless the resolved IP aligns perfectly and is interpreted correctly by the daemon at that moment.

Any suggestions?

[Edit2]

One step further... I changed the FQDN to User distuinguished FQDN (simply put a user in front of my FQDN for PSK identity): user@jashdejvmiuqlachhsqaxs.siteb.example.com).

This came up immediately. I will observe this further and see if it helped..
#7
Interesting. Thanks for the classification! I just started the new connections and it went up flawlessly immediately!

[Edit] After testing, this was probably a leftover observation from a previous (legacy) connection.
#8
Ok, I would have preferred keeping my current WAN IP as the identifier, but I can use the FQDN from the dyndns-url I am using to tell the other side my identity. It will be somewhat off between the time my provider sends me a new WAN address and the time my script was able to update the FQDN dyn dns. I will try. Thanks!
#9
Thank you. I am reading this section over and over and I can't seem to find the information you're trying to point me to.

There are two paragraphs regarding PSK:

QuoteWhen migrating Pre-Shared Key type tunnels to connections, make sure to add an entry in the "Pre-Shared Keys" module as well. If both ends should use their own identifier, fill in both local and remote values. The legacy module requested this information in the phase 1 page and wrote the same information to the secrets.

This tells me to "fill in both local and remote values", but not how.

Further down it says:

QuoteSince OPNsense uses the new Strongswan format also for legacy tunnels, it is rather easy to convert a tunnel manually when downloading the swanctf.conf file from the machine.

But when I download my Legacy swanctf.conf, I can only see my current WAN IP Address - I can't set this IP address as "My identifier", as it will regularly Change. I need some automation to replace the former (legacy) "My IP Address" Feature, which is not available in the new PSK-dialogue.

#10
I heavily rely on my IPSEC site-to-site policy VPN and waited until now to do the legacy migration.

I got until the pre-shared Key step, where in my legacy setup I used "My IP address" for phase 1 (Auth) in the field "My identifier".

In the new IPSEC setup, there is no drop-down for selecting "My identifier". I have a dynamic IP-address on one side, so I cannot enter a static ip address here.
It says:
> This can be either an IP address, fully qualified domain name or an email address.

What do you suggest selecting here, going forward with the migration?
#11
23.7 Legacy Series / Re: radvd not starting
December 17, 2023, 04:45:08 PM
Great, thank you for the confirmation!

I think this was new, which is why radvd not starting caught my eye and got me worried.
#12
23.7 Legacy Series / Re: radvd not starting
December 17, 2023, 03:47:10 PM
Thank you. So this means this is normal and should be expected, when IPv6 is disabled?
#13
23.7 Legacy Series / [SOLVED] radvd not starting
December 17, 2023, 08:15:24 AM
Since the last update, my radvd is not starting. It looks like playing with IPv6 (and finally disabling it again), I have  recurring problems with the DHCPv6 and radvd service.

Tried to reset everything following https://forum.opnsense.org/index.php?topic=34584.0 this did not solve my issue. radvd still not starting, even if clicked manually. There is also no error in logs.

When following the above guide, I got:


2023-12-17T08:06:34 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb3'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'
2023-12-17T08:06:31 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb2'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'
2023-12-17T08:06:27 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb1'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'


But I cannot assign this to any specific action.

Where would I start debugging starting of radvd?
#14
@Patrick M. Hausen, @franco - many thanks for the explanation! Indeed, I expected I was _wrong_, was just looking for this piece of information. Maybe discussions like these help at some point make the gui or docs more self-explanatory. Of course, nothing helps against ignorant users (I hope I am not one of them).
#15
You can create your own script to push/update using a custom DNS API. I've added an example (Cloudflare) here:
https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/#dns-setup

(because the Cloudflare implementation available through OPNsense plugins did not work)