"Recent posts
#1
26.1, 26,4 Series / 26.1.X Wireguard - add net def...
Last post by systeme - Today at 09:20:23 AMHello,
Since upgrading to version 26.1.2 (or 26.1.7), we've been seeing this error in the WireGuard logs at startup:
2026-04-21T07:59:30
Error
wireguard
/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/route add -'inet' default 'IP_WAN_GATEWAY'> returned exit code 1 and the output was "add net default: gateway IP_WAN_GATEWAY fib 0: Invalid argument"
Configuration IP_WAN_GATEWAY :
The priorities on the gateways have been changed since the last changelog (26.1.2), but the same errors persist.
Opnsense is virtualized, so there are no groups to configure at the gateway level.
Do you have any suggestions on how to avoid this error in the future?
Thank you in advance,
Best regards,
Since upgrading to version 26.1.2 (or 26.1.7), we've been seeing this error in the WireGuard logs at startup:
2026-04-21T07:59:30
Error
wireguard
/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/route add -'inet' default 'IP_WAN_GATEWAY'> returned exit code 1 and the output was "add net default: gateway IP_WAN_GATEWAY fib 0: Invalid argument"
Configuration IP_WAN_GATEWAY :
The priorities on the gateways have been changed since the last changelog (26.1.2), but the same errors persist.
Opnsense is virtualized, so there are no groups to configure at the gateway level.
Do you have any suggestions on how to avoid this error in the future?
Thank you in advance,
Best regards,
#2
26.1, 26,4 Series / Re: This makes me want to cry!...
Last post by roohoo - Today at 09:17:37 AMThank you for the suggestions regarding time, but the system time is perfectly correct and doesn't change. As you can see from the original screenshot I posted, it's only the webGUI reporting the uptime incorrectly. The Current- and Last configuration change- times are spot-on. The time reported by the date command in the shell is the same.
On each of the new machines, I have performed a clean, bare install and gone on to configure just the interfaces. I have not imported any configurations.
I have tried a complete return to BIOS factory settings as well as curating each BIOS option individually. Neither makes a difference. Google Gemini, ChatGPT and Grok all told me that the problem was almost certain to be (with the Intel chips) the c-states configuration but disabling this made no difference either.
I hope to get a chance to investigate where my RAM is going to this evening...
Again, thank you all.
On each of the new machines, I have performed a clean, bare install and gone on to configure just the interfaces. I have not imported any configurations.
I have tried a complete return to BIOS factory settings as well as curating each BIOS option individually. Neither makes a difference. Google Gemini, ChatGPT and Grok all told me that the problem was almost certain to be (with the Intel chips) the c-states configuration but disabling this made no difference either.
I hope to get a chance to investigate where my RAM is going to this evening...
Again, thank you all.
#3
Zenarmor (Sensei) / Re: os-sunnywalley plugin inst...
Last post by raczzoltan - Today at 09:09:48 AMHi,
I tested it in a virtual machine in my laptop. That was the last thing I did't try. I tried it in a fresh install and also did not work then I tried it on a diferent network and then it worked. So It is definitly a network problem and I think that the ISP router after my OPNsense box blocks it but I don't have access to that. That is my best guess. So it is definitly not a bug in OPNsense. What I don't understand that I can ping the zenarmor update server but the update dont work.
Thank you for the help!
I tested it in a virtual machine in my laptop. That was the last thing I did't try. I tried it in a fresh install and also did not work then I tried it on a diferent network and then it worked. So It is definitly a network problem and I think that the ISP router after my OPNsense box blocks it but I don't have access to that. That is my best guess. So it is definitly not a bug in OPNsense. What I don't understand that I can ping the zenarmor update server but the update dont work.
Thank you for the help!
#4
26.1, 26,4 Series / Re: WAAgent Linux broken after...
Last post by franco - Today at 06:45:33 AMIf you got the image from us then contacting sales@deciso.com with reference to this thread would be a good next step.
There's also an upgrade log in the firmware audits you can share that as well.
Thanks,
Franco
There's also an upgrade log in the firmware audits you can share that as well.
Thanks,
Franco
#5
General Discussion / Re: How do IPv6 Router Adverti...
Last post by OPNenthu - Today at 05:56:09 AMThere's only one concern I have and it may be a nothing-burger, but I'll mention it anyway for discussion.
Based on what @mooh wrote the default for these devices is that they use link-local addresses, which limits their access to what the hub provides them from its own uplink to the IOT network. That is easy enough to firewall because all you would have to do is block the hub and everything downstream of it is also walled off.
By necessity of your design, since you split the hub off to a separate VLAN, it now needs to advertise ULAs downstream because LL addresses are not routable. The issue now is, if you're not careful, you could potentially open a hole whereby the connected matter devices gain network access via some ULA route. You've weakened the default security which you then need to mitigate with your own routing/rules.
All fine and good if you understand what you're doing, but I wouldn't recommend it for family & friends. IMO, it's cleaner and safer to put the thread hub / border router on the IoT net. Give it a static IP or add its MAC to an alias. Then if you really must constrain it and its downstream devices to the IOT network and nothing else (not even internet), a rule like this could do:
Now they are not able to get beyond the IOT network, but your controllers on other VLANs can still get to them (if their rules permit).
Based on what @mooh wrote the default for these devices is that they use link-local addresses, which limits their access to what the hub provides them from its own uplink to the IOT network. That is easy enough to firewall because all you would have to do is block the hub and everything downstream of it is also walled off.
By necessity of your design, since you split the hub off to a separate VLAN, it now needs to advertise ULAs downstream because LL addresses are not routable. The issue now is, if you're not careful, you could potentially open a hole whereby the connected matter devices gain network access via some ULA route. You've weakened the default security which you then need to mitigate with your own routing/rules.
All fine and good if you understand what you're doing, but I wouldn't recommend it for family & friends. IMO, it's cleaner and safer to put the thread hub / border router on the IoT net. Give it a static IP or add its MAC to an alias. Then if you really must constrain it and its downstream devices to the IOT network and nothing else (not even internet), a rule like this could do:
Code Select
Interface: IOT
Quick: <checked>
Action: Block
Direction: In
Protocol: any
Source: { dirigera }
Dest: !IOT_net
Now they are not able to get beyond the IOT network, but your controllers on other VLANs can still get to them (if their rules permit).
#6
26.1, 26,4 Series / Re: This makes me want to cry!...
Last post by lmoore - Today at 05:03:41 AMQuote from: roohoo on April 20, 2026, 09:20:35 PMNot enabled ☹️
Prior to my previous post, I had disabled this option too, but its effect was inconclusive.
Yesterday afternoon (my time: GMT +08:00), I re-enabled the option and left it running overnight.
Looking this morning, this is how the process appears in top (time is BST) - viewed with and without listing threads:
Quotelast pid: 13247; load averages: 0.19, 0.30, 0.30 up 1+07:11:09 00:46:42
66 threads: 1 running, 65 sleeping
CPU: 0.3% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.6% idle
Mem: 75M Active, 101M Inact, 5424K Laundry, 466M Wired, 204M Buf, 1325M Free
Swap: 8192M Total, 189M Used, 8003M Free, 2% Inuse
PID USERNAME PRI NICE SIZE RES SWAP STATE C TIME WCPU COMMAND
94669 hostd 20 0 31M 2996K 0B bpf 3 0:01 0.00% /usr/local/bin/hostwatch -c -S -p -P /var/run/hostwatch/hostwatch.pid -d /var/db/hostwatch/hosts.db -u hostd -g hostd{hostwatch}
94669 hostd 20 0 31M 2996K 0B uwait 2 0:01 0.00% /usr/local/bin/hostwatch -c -S -p -P /var/run/hostwatch/hostwatch.pid -d /var/db/hostwatch/hosts.db -u hostd -g hostd{hostwatch}
last pid: 18592; load averages: 0.17, 0.29, 0.30 up 1+07:11:17 00:46:50
54 processes: 1 running, 53 sleeping
CPU: 0.6% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.4% idle
Mem: 75M Active, 101M Inact, 5424K Laundry, 466M Wired, 204M Buf, 1325M Free
Swap: 8192M Total, 189M Used, 8003M Free, 2% Inuse
PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME WCPU COMMAND
94669 hostd 2 20 0 31M 3008K 0B uwait 2 0:01 0.02% /usr/local/bin/hostwatch -c -S -p -P /var/run/hostwatch/hostwatch.pid -d /var/db/hostwatch/hosts.db -u hostd -g hostd
I've since rebooted this system and it is back to using 8GB of RAM.
Perhaps the issue could be something in the environment, like in this story - https://www.theregister.com/2026/04/17/on_call/?td=rt-4a
When you installed OPNsense on the new computers, did you restore the configuration from a file or did your reconfigure from scratch?
As far as I can ascertain, based upon these settings in OPNsense, FreeBSD will periodically write the OS time to the RTC;
- machdep.disable_rtc_set: 0
- machdep.rtc_save_period: 1800
There have probably been changes, but my understanding is that BSD would read the RTC at start-up and rely upon other sources for time whilst running. During shut down, the TOD would be written back to the RTC.
Perhaps you could post the current listing of /var/run/dmesg.boot.
At this time it appears you have two problems;
- OPNsense detects an anomaly whereby the uptime is reported to be around 50 years
- Your system is may be using excessive amounts of memory
Have you tried performing a Factory Setting of the BIOS and not making any changes to it and then installing OPNsense?
I don't have IPv6 in my environment I can test this.
Did you alter anything in Services:Network Time: General?
It may be worth removing all the listed servers here so OPNsense doesn't attempt to synchronise the time from an external source.
To obtain more information about the processes in top, you could use the following in a wide screen session;
top -awo res -s 1
#7
25.1, 25.4 Legacy Series / Re: Wireguard issue(s)
Last post by unknownplant - Today at 04:58:13 AMWell, I just discovered this built in cron script called "Renew DNS for WireGuard on stale connections" that replaced my manual intervention. Woohoo
#8
General Discussion / Re: How do IPv6 Router Adverti...
Last post by barney - Today at 04:28:19 AMYep - sort of...
It isolates the Thread Border Router (Dirigera) and all the matter devices connected through it to a VLAN where I can prevent both internet access and also access to any other VLANs (general internal, cameras etc.)
I'm not sure. I could restrict access to the Dirigera itself as it has a known IP, but I'm not sure if I could restrict access to the thread devices behind it. The RA that the Dirigera broadcasts to its VLAN adds a direct route to all devices on the ML-EID (thread network) so I'm not sure if those packets still go via the router or not, and so could be intercepted by the firewall.
As it currently stands, all I have are three firewall rules:
All other access to/from VLAN40 is blocked by default except for some common DNS / NTP etc stuff, although I'm still analysing the logs and may need some reverse access from the ML-EID network back to the OpenHab server.
It isolates the Thread Border Router (Dirigera) and all the matter devices connected through it to a VLAN where I can prevent both internet access and also access to any other VLANs (general internal, cameras etc.)
QuoteWould you be able to achieve the same with a firewall rule in an IoT VLAN?
I'm not sure. I could restrict access to the Dirigera itself as it has a known IP, but I'm not sure if I could restrict access to the thread devices behind it. The RA that the Dirigera broadcasts to its VLAN adds a direct route to all devices on the ML-EID (thread network) so I'm not sure if those packets still go via the router or not, and so could be intercepted by the firewall.
As it currently stands, all I have are three firewall rules:
- IPv4 access from OpenHab to Dirigera itself.
- IPv6 access from OpenHab to the ML-EID network (fd2c:d79a:65f9:1::/64)
- mDNS between VLAN20 and VLAN40
All other access to/from VLAN40 is blocked by default except for some common DNS / NTP etc stuff, although I'm still analysing the logs and may need some reverse access from the ML-EID network back to the OpenHab server.
#9
25.1, 25.4 Legacy Series / Re: Wireguard issue(s)
Last post by unknownplant - Today at 04:18:44 AMI have had the same issue for over a year now.
My setup is that of two opnsense routers with a site to site wireguard connection.
Only site 1 is properly exposed to the internet while site 2 is behind a nat with no port opened to it.
Thus my setup requires site 2 to reach out to site 1 via a DNS endpoint.
The issue arises when site 2 wireguard does not update the endpoint ip address when site 1 has its dynamic public IP changed.
It is unfortunate that site 2 wireguard keeps the IP cached and doesnt update it when the connection fails.
My only remedy is to restart the wireguard service on site 2 for the new IP to be loaded.
My setup is that of two opnsense routers with a site to site wireguard connection.
Only site 1 is properly exposed to the internet while site 2 is behind a nat with no port opened to it.
Thus my setup requires site 2 to reach out to site 1 via a DNS endpoint.
The issue arises when site 2 wireguard does not update the endpoint ip address when site 1 has its dynamic public IP changed.
It is unfortunate that site 2 wireguard keeps the IP cached and doesnt update it when the connection fails.
My only remedy is to restart the wireguard service on site 2 for the new IP to be loaded.
#10
General Discussion / Re: How do IPv6 Router Adverti...
Last post by OPNenthu - Today at 02:32:25 AMThis might come in useful in the future. Just so I understand: the problem this solves for you is that it isolates the Thread hub (the Dirigera) to a VLAN where you can disable internet access?
Would you be able to achieve the same with a firewall rule in an IoT VLAN?
Would you be able to achieve the same with a firewall rule in an IoT VLAN?
