Messages

Hello,
I have ordered and received the token for ETPRO Telemetry edition and has added the token on
the Download page and have saved and then press Download.

But constantly seeing some issues in OpnSense General log hat I could not figure out.

I have added the token and pressed SAVE and done Download and Update again but still the same. Not sure if it is a bug?

2026-04-27T20:37:00        Error                  send_telemetry.py                telemetry token missing in /usr/local/etc/suricata/rule-updater.config
.
.
2026-04-27T20:36:00        Error                  send_telemetry.py                telemetry token missing in /usr/local/etc/suricata/rule-updater.config
2026-04-27T20:35:00        Error                  send_telemetry.py                telemetry token missing in /usr/local/etc/suricata/rule-updater.config
2026-04-27T20:34:00        Error                  send_telemetry.py                telemetry token missing in /usr/local/etc/suricata/rule-updater.config
2026-04-27T20:33:00        Error                  send_telemetry.py                telemetry token missing in /usr/local/etc/suricata/rule-updater.config

Also, here is a snippet of /usr/local/etc/suricata/rule-updater.config as well. The token match the one I received in the email.

SOLVED: As i did not get any response I tried to debug it myself and after a debugging session I found that the fault is not a missing or wrong token but rather a missing folder /var/log/suricata/ that for some reason was gone even if I have had IP enabled several times.

I have sent an email to the handler of the "ET Pro Telemetry Edition" plugin with more in-depth details.

Basically the send_telemetry.py script at one point checked that the folder /var/log/suricata/ exists and if it doesn't it sends a very missleading error in the log.   "Error                  send_telemetry.py                telemetry token missing in /usr/local/etc/suricata/rule-updater.config"

The handler realized that it was a bug in the code where two different if else statements was in the wrong order:

Incorrect before fix.
    if cnf.token is not None:
        if os.path.isdir(args.log):
.
.
                exit_code = 0
        else:
                syslog.syslog(syslog.LOG_ERR, 'telemetry token missing in %s' % args.config)
    else:
            syslog.syslog(syslog.LOG_ERR, 'directory %s missing' % args.log)

Correct order
    if cnf.token is not None:
        if os.path.isdir(args.log):
.
.
                exit_code = 0
        else:
            syslog.syslog(syslog.LOG_ERR, 'directory %s missing' % args.log)
    else:
        syslog.syslog(syslog.LOG_ERR, 'telemetry token missing in %s' % args.config)

//Dan

Best regards
Dan Lundqvist
Stockholm, Sweden

I made a quick little lazy for this if anyone else needs it.  :-)

//Danne

You only have the following in PSK setting:
Local Identifier    Here I use my WAN IP.
Remote Identifier    Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
Pre-Shared Key      Our joint and unique PSK as set in both ends.
Type                PSK

There is really no "Id" to specify here apart from Local and Remote identifier.

The ID settings in question are in the local and remote authentication settings. ID is short for identifier.

In the local specify the same string as the local identifier in the PSK.
And in the remote the same as remote identifier.

I think that did the trick.  :-)
I used the same
PSK Local Identifier = xx.xx.xx.xx IP    -> Local Auth ID = xx.xx.xx.xx IP
PSK Remote Identifier = xxx.domain.com   -> Remote Auth ID = xxx.domain.com

and now the link came up OK.  :-)

Thanks so much for the help.   I have been using computers for ages and IPSec
for a long time but you never get to old to learn something new. :-)
I understood it was something simple, it is just to get how the new setups works
so I could work with it and not against it.

It is good that I could remove the old legacy connections and use the new StrongSwan Connections.

Anyway, thanks SO much for you input and help. Really appreciated.

Best regards
Dan Lundqvist

For testing the new connection you have to disable the legacy, however.
Yes, I totally understand that and that was done.

The are the authentication settings.
In local you define, how your server authenticates on the remote site.
And in remote you define, how the remote site has to authenticate on your server.

I think, it's necessary to state a local and a remote identifier in the pre-shared key settings. And then use the same in the local and remote settings of the connection. This is the only way, IPSec can select the proper PSK in case, you've multiple.
This means, you will have to enter the respective ID from the PSK in the authentication settings.

You only have the following in PSK setting:
Local Identifier     Here I use my WAN IP.
Remote Identifier    Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
Pre-Shared Key       Our joint and unique PSK as set in both ends.
Type                 PSK

There is really no "Id" to specify here apart from Local and Remote identifier.

Recent versions set a unique requid automatically, as I've read. This didn't work in the past, however. So I've stated a unique one (above of 10) for each tunnel.
Ok, I will try that.

You should remove the check at default and select a proper for your needs here. The same is true for the phase 1.
According to your screenshot of the legacy settings, you need aes256-sha256-modp1024[DH2].
Done...

You mean in the new connections?
As mention, you have to state in the PSK  and authentication settings.

In legacy you have
Phase 1 proposal (Authentication)
  Authentication method  Mutual PSK
  My identifier    <WAN IP>
  Peer identifier       Distinguished name    an xxx.yy.xx domain address.

But I kind of have that in PSK settings, just in slightly different way
Local Identifier     Here I use my WAN IP.
Remote Identifier    Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)

//Danne

[static]

Hi,
Thanks for answering.

The "Local addresses" is my public WAN IP address that is static, not DHCP or DHCP reserved.
My WAN is not double-NATed but real public static IP. Internet reaches my WAN directly.
I even have recursive DNS lookup on two of my three IPs I "own" (helps running my mailserver as more legit)

The "Remote address" is a domain-name the resolves to a A-record in DNS.

And is using the exact IP/PSK and similar in my IPSec legacy working totally fine and is up
and could reach network on the other side of IPSec.

From what I could see, both local and remote accepts "single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP address ranges."

I do not use pools so that is switched off.

I'm a little puzzled about the Local and Remote Authentication screens.
The connection is the only one selectable in the drop down menu and auth = PSK
but don't know if I need to specify anything in the "Round" and "ID" ?

If I read this correctly it is more to do when using certificates.

"IKE identity to use for authentication round. When using certificate authentication
the IKE identity must be contained in the certificate; either as the subject DN or
as a subjectAltName (the identity will default to the certificate's subject DN if
not specified). Refer to https://docs.strongswan.org/docs/5.9/config/identityParsing.html
for details on how identities are parsed and may be configured."

I have not been needing to create any certificate in the legacy IPSec OpnSense setup.

The Children (aka ~= Phase 2) is having the following:
Connection = <connection name>
Mode = Tunnel
Policies = YES.  (As I am not using VTI in the setup but a straight old fashion IPSec.)
Start action = Start
DPD action = Start
Reqid = <blank>    This one I am not sure if needs to be populated with anything if not using manual certificates ?
ESP proposals = default
Local = 192.168.120.0/24    ; this is my LAN
Remote = 192.168.100.0/24    ; this is remote LAN.

In the PreSharedKey setting i have setup a PSK.
Local Identifier = <my public static IP>
Remote Identifier = a specific DNS A-record domain name
Pre-Shared Key = Our PSK shared key that works in legacy IPSec right now.
Type = PSK

I just realized one thing.

In Legcay IPSec you are manually defining "My identifier" and "Peer identifier"
where in my legacy setting I could not find that setting !?

My identifier = My IP address  (my WAN IP address same as defined in Connections "Local addresses".
Peer identifier = Distinguished name = <a specific domain name like "xxx.yyy.zz" format.

There must be something I'm missing but could not find out what that is.

Firewall is set to following on WAN:
- Allow ESP for IPSec (IPv4)
- Allow IKE port500 for IPSec. (Udp ISAKMP (500)
- I also have "IPSEC-NAT-T (4500)" on WAN. (Allow IPSec IKEv2 MOBIKE NAT-Traversal)

Best regards
Dan Lundqvist
Stockholm, Sweden

Ps. I have using OpnSense for many years and pfSense (before they stagnated and I moved to much better OpnSense and never looked back. :-)
I have been using both legacy IPSec standard but also VTI tunnels (OpnSense<->OpneSense) with at least
3 VTI plus one standard IPSec at the same time.

Anecdote is that I have had my own domain since 2000, and been running a mailserver since late 2002 with at least 1-2
real persons since day one entrusting me as their main email provider for 20+ years. :-)

Last screenshot.

//Dan Lundqvist

More screenshots.

//Danne

Hello,

I am running 26.1.5 and have a IPSec legacy connection setup working OK to a destination node
an is trying to replace it with the new IPSec Connections but it fails all the time.

I have tried to migrate the settings from old to new at the best of my abilities but it does not come up. :-/
Is there anything specific I need to think about ?

Here is the IPSec settings and will respond to myself with more screenshots of new IPSec and old.

//Dan Lundqvist

Thanks for the reply.
Good that it is not just me then.

Even if the old dashboard is a bit outdated (hower not bad in my opinion) but it was strict sizes and aligning which would make small screens behave better and large screens also behave in a predictable way.

Now it feels cluttered and not well adjusted.
I agree with your statement and think this needs to be revisited with someone having better experience with UX design to get back to what was powerfull with the old dashboard design and structure BUT with a newer more updated and agile design.

Best regards
Dan Lundqvist

Hello,
Not up to start a flamewar but is it more usets than me that agree with me that the new dashboard does NOT play well with mobile devices. But also placement, size and movement of widgets is more problematic than on the old dashboard.

Widgets placed in a three column way, was automatically
stacked 1+2+3 on a mobile display in the old versions
But in the new dashboard mixes the items mishmash
from all stacks and there is no strict discipline that it
stacks column 1,2,3,n in that order.
Another problem also seen is that certain widgets
Is offshifted to the right on mobile display so widgets
is not exactly on top of each other.
This was much better in old dashboard where widget
width was always the same and they was always
left-shifted.

I can agree that some of widgets looks nicer in the new
gui but some works needs to be done to make widget
aligning better and also widget sorting more strict
to the old way of column 1,2,3,n.

That is my 2 cent worth of constructive criticism.
Don't get me wrong,  I really do like Opnsense and
has been running it for many years and have no
plans of swapping.

Best regards
Dan Lundqvist
Stockholm, Sweden

[VPN: IPsec: Status Overview]

Since upgrade to OPNsense 23.1.1_2, VPN: IPsec: Status Overview shows ALL Remote IP as "%any".
Also the IPSec Widget shows  "%any" in the "(...)

Br Dan Lundqvist

UPDATE: Seems to have been solved in 23.1.3
Now updated with "0.0.0.0/0,::/0" both in IPSec Status and in Widget.

Does Synology has some ACPI options to enable?

Nope, not that I have found.
It is based on a Intel Celeron J4125 2GHz but don't  have access to any BIOS settings as it boots up nativly.
Have not found any settings for it in GUI.

I have even tried "shutdown -p now" from commandline in OPNsense and it still does not shutdown the VM as seen in the VM Manager in Synology. :-/

Have tried both legacy and UEFI....
It is a bit of a bummer. :-|

I am not saying it is a fault in OPNSense, don't get me wrong.

Bst regards
Dan Lundqvist

UPDATE:
Just as a test (to see if FreeBSD could shutdown VM in Synology at all) I installed latest pfSense in a VM.
An then tried to shutdown VM from Synology VM manager and it both started the shutdown in pfSense window also managed to shutdown completly so Synology VM and FreeBSD are able to do it.
I tested with the exact same VM for both installations just to compare apples and apples.

(yes, I know, opnsense vs pfsense battle/flamewar. Don't worry. I made the decision to go away from pfSense to opnsense and have no plans on going in the oposite direction. :-)

I checked the difference in FreeBSD version
OPNSense: FreeBSD 13.1-RELEASE-p5
pfSense: FreeBSD 12.3-STABLE

Conclusion: 
pfSense on FreeBSD 12.3 stable are able to shutdown OK but opnsense on FreeBSD 13.1 p5 is not.
Reason unknown right now.
Same Synology HW/SW, Same VM BIOS, Same VM settings.

UPDATE2:
I have now tested the following to see if any of them works:
OPNsense 21.1   FreeBSD 12.1 (HardenedBSD)          OK, shuts down and power off OK.
OPNsense 21.7   FreeBSD 12.1 (HardenedBSD)            OK, shuts down and power off OK.
OPNsense 22.1   FreeBSD 13-STABLE                  NOK, does not power off.
OPNsense 22.7   FreeBSD 13.1-RELEASE               NOK, does not power off.

Conclusion: Something has changed between FreeBSD 12.1 -> FreeBSD 13 (and/or OPNsense 21.x -> 22.x) causing it to stop working in shutting it down when running in Synology Virtual VM. (QEMU/KVM). :-/

Found the following thread. Will try the settings to see if it helps.
https://forums.freebsd.org/threads/cannot-shutdown-reboot-after-upgrade-to-13-0-release.80199/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253175

Disabling the USB interface seems helping it to get stuck in uhub0: detached indefinetly and is now able to shut down OK.  Also added the tunable "hw.kern.efi.poweroff=0" but that on it's own did not help. Only by disabling USB interface.
Adding the tuneable "hw.usb.no_shutdown_wait=1" but did not help as long as I have USB hub enabled.
Only swithing USB hubb off helps it to truly shut down. Lucky for me I do not need the USB hub in my VM.

I think someone needs to look into this as it seems to be more people having same issue on FreeBSD 13 and it seems to be related to that

Seems like the issue is related to that it won't shutdown the VM. It waits at uhub0: detached indefinetly.
t seems there are situations in which a none USB related issue is at work (referring here to SirDice's post #3), preventing the machine to power off. 

A comment regarding running in VirtualBox VM they stated
"Setting the VM's system chip set to ICH9 (instead of the default PIIX3), with enabled USB controller, and default hw.efi.poweroff=1 the VM powers off immediate after uhub0: detached.
Apparently there is a relation between the chip set in use and a complete power off of the VM."

[192.168.121.2]

Hello,

I have an issue that has been going on now for some time that is very anoying and still after 22.7.6 upgrade persists.

BACKGROUND:
I have 4 IPsec tunnels (one standard and 3 VTI) and a OpenVPN Server configured

PROBLEM:
What happens is that every time I reboot the opnsense, two of the static routes configured gets corrupted and selects a different gateway. Happens every time I reboot. If I remove and set them up again the routing table becomes correct and routing starts working OK.

After REBOOT
Destination             Gateway              Flags    Use     MTU     Netif         Netif(name)
192.168.10.0/24     192.168.121.2   UGS     NaN     1500   ovpns1     OVPN_SERVER
192.168.20.0/24     192.168.121.2   UGS     NaN     1500   ovpns1     OVPN_SERVER

After reconfigure 192.168.10.0 and 192.168.20.0
Destination             Gateway              Flags    Use     MTU     Netif         Netif(name)
192.168.10.0/24     link#8                 US        NaN     1400   ipsec1     HENRIK_VTI
192.168.20.0/24     link#9                 US        NaN     1400   ipsec3     HENRIK_MAMMAPAPPA_DIREKT

Have tried all sorts of things but problem still persists and ONLY one these two routes...
Feel it is a bug lurking...

Has anyone else seen this problem and could someone at opnsense have a look.
I have attached some screenshots and logfiles.

Contact me with pm for more screenshots, logs and I could include the config.xml as well.

UPDATE:
I have now found the culprit.

I had a by misstake defined a bunch of networks in OpenVPN Server config "IPv4 Remote Network" which caused it to highjack these nets towards the ovpns1 interface instead of the one I had defined in the routing table. Problem is now solved...




Best regards
Dan Lundqvist
Stockholm, Sweden

Is there no one who has stumbled on to this problem running OpnSense in a Synology VM ?

I do have the OpnSense plugin "QEMU Guest Addon" installed.  Even tried to re-install but same result.

Best regards
Dan Lundqvist (mrzaz)

Hello,

I am trying to run OpnSense in a Synology DS920+ Virtual Manager VM which works OK. No problems.
However, I have some issues with halting OpnSense. It halts Opnsense but does not halt the VM itself.
Tested from the GUI and CLI to shut down OpnSense.

Have tested to install the QEMU plugin in OpnSense but no difference.
- Operating System = Other (as i am installing a VM containing FreeBSD)
- Legacy BIOS
- Setup 2 vSwitch entries with WAN in one (LAN2) and LAN in the other (LAN1) and added 2 NICs. Both VirtIO.
- 1 CPU (during testing)
- videocard vga
- Normal priority

All works OK with the VM, just the halt that does not halt the VM itself, only the content of the VM (OpnSense).
Anyone have any ideas how to get this working OK ?

Best regards
Dan Lundqvist (mrzaz)