"Recent posts
#1
26.7 Series / Problems with upgrade from 26....
Last post by Vulhunter25 - Today at 12:59:43 AMSo I upgrade from 26.1 latest to 26.7.3 today. All seemed to go well but after final reboot, internet connection is not working. Provider is xfinity/ Comcast. The wan interface seems to dhcp but the system log has the following messages:
Interfaces.php: ROUTING: refusing to set interface route on addresses wan(vtnet1)
Error opnsense/interfaces.php ROUTING: not a valid wan interface gateway address: 'missing'
In interfaces:overview the wan shows an ipv4 address and a gateway address.
I did see notes about routing issues and set the tunable net.route.algo.inet.algo to radix4 this had no effect on issue.
This is a virtualized firewall in proxmox that has worked fine for 5 years.
Advice on where to go from here?
Interfaces.php: ROUTING: refusing to set interface route on addresses wan(vtnet1)
Error opnsense/interfaces.php ROUTING: not a valid wan interface gateway address: 'missing'
In interfaces:overview the wan shows an ipv4 address and a gateway address.
I did see notes about routing issues and set the tunable net.route.algo.inet.algo to radix4 this had no effect on issue.
This is a virtualized firewall in proxmox that has worked fine for 5 years.
Advice on where to go from here?
#2
General Discussion / Re: WAN out connection Issues
Last post by Tetra - Today at 12:48:27 AMI have applied what you have suggested and sadly no improvements and no new ping/reachability changes. The only custom things I have done (outside of your suggestions) to OPNsense is set up DNS over TLS to cloudflare and a few other DNS servers with firewall rules. I have also created the LAN point to be a routed interface with a /30 IP. The routed interface is pointing to my cisco switch routed port. On that switch I have a DCHP service enabled and the pools give the gateway to the user their respective SVI on that switch. I don't use OPNsense for dhcp services and none of my vlans or dhcp pools are held/conflict with OPNsense. This set up is entirely physical. The WAN interface is getting a IP from the ISP router's DHCP. Both IPv4 and IPv6 gateways with proper addressing are active and online.
#3
Tutorials and FAQs / Re: [HOWTO] NordVPN Wireguard ...
Last post by MagikMark - September 04, 2026, 10:31:58 PMThanks for the reminder and guidlines. I really appreciate it. I have migrated everything.
Just wondering if OPNsense now is supporting Interface Group in NAT? I have 7 tunnels tried using "Wireguard Group" in NAT and it seems experience is a lot snappier and latency is lower
Just wondering if OPNsense now is supporting Interface Group in NAT? I have 7 tunnels tried using "Wireguard Group" in NAT and it seems experience is a lot snappier and latency is lower
#4
26.7 Series / Re: Running OPNsense 26.7 on a...
Last post by s5n - September 04, 2026, 09:53:21 PMQuote from: BigFreddy on September 03, 2026, 06:15:09 PMIs it possible to run the latest version of OPNsense purely from a USB stick as a hard disk? I heard that many people did it but is it still supported and what do I need to look out for or change within settings to make it run properly?
Please keep in mind that USB sticks typically don't have SMART or similar interfaces, so if you want to run this setup for a longer time, you will have no proper means to check for flash cell wear or other issues.
#5
26.7 Series / Re: Upgrade 26.1 to 26.7 - bnx...
Last post by newsense - September 04, 2026, 09:32:29 PMOpen a GitHub issue in OPNsense/src and mention this thread.
#6
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by meyergru - September 04, 2026, 08:33:43 PMThanks, that rules out both of my DNS-related guesses.
In particular, the fact that restarting Unbound does not help, while restarting the inbound WireGuard instance does, strongly suggests that the problem is not DNS itself but the runtime state of the WireGuard interface after boot.
Also, I would not necessarily assume that your two observations have the same cause:
1. "Configuring WireGuard" taking a long time during boot may well be caused by S2S peers whose endpoints have to be resolved. That is to be expected, because the DNS of the endpoints is not yet resolvable and only gets corrected on first run of the cron job.
2. The C2S clients being unable to use the firewall itself as DNS afterwards is probably a separate problem with the C2S WireGuard interface not being initialized correctly.
So I would compare the actual WireGuard state before and after restarting the inbound instance.
While the problem exists, please show:
Then restart only the affected inbound WireGuard instance and show the same three commands again.
In particular, check whether the configured tunnel IP address of the firewall is actually present on `wgX` in the broken state. If that address is missing or wrong, it would explain the symptoms very nicely: routed traffic through the tunnel may still work, while DNS to the firewall's own WG address cannot.
Another useful test while it is broken would be:
If the DNS packets arrive on `wgX`, we know that the tunnel itself transports them and can concentrate on local delivery/interface configuration instead of DNS.
At this point I would first look at the before/after difference rather than try another workaround.
In particular, the fact that restarting Unbound does not help, while restarting the inbound WireGuard instance does, strongly suggests that the problem is not DNS itself but the runtime state of the WireGuard interface after boot.
Also, I would not necessarily assume that your two observations have the same cause:
1. "Configuring WireGuard" taking a long time during boot may well be caused by S2S peers whose endpoints have to be resolved. That is to be expected, because the DNS of the endpoints is not yet resolvable and only gets corrected on first run of the cron job.
2. The C2S clients being unable to use the firewall itself as DNS afterwards is probably a separate problem with the C2S WireGuard interface not being initialized correctly.
So I would compare the actual WireGuard state before and after restarting the inbound instance.
While the problem exists, please show:
Code Select
ifconfig wgX
wg show wgX
netstat -rn -f inet
Then restart only the affected inbound WireGuard instance and show the same three commands again.
In particular, check whether the configured tunnel IP address of the firewall is actually present on `wgX` in the broken state. If that address is missing or wrong, it would explain the symptoms very nicely: routed traffic through the tunnel may still work, while DNS to the firewall's own WG address cannot.
Another useful test while it is broken would be:
Code Select
tcpdump -ni wgX port 53
and then try a DNS lookup from the client.If the DNS packets arrive on `wgX`, we know that the tunnel itself transports them and can concentrate on local delivery/interface configuration instead of DNS.
At this point I would first look at the before/after difference rather than try another workaround.
#7
26.7 Series / Re: Unbound stopps suddenly
Last post by franco - September 04, 2026, 08:10:42 PMLast time Michael checked he said the ports binaries didn't work, but that may have been a long time ago.
Not super comfortable to bring such a thing into the supported ecosystem and people making AI plugins for it rather sooner than later. There's probably more noise and support questions then.
Other core devs will probably have similar views but we can talk about it at EuroBSDCon.
Cheers,
Franco
Not super comfortable to bring such a thing into the supported ecosystem and people making AI plugins for it rather sooner than later. There's probably more noise and support questions then.
Other core devs will probably have similar views but we can talk about it at EuroBSDCon.
Cheers,
Franco
#8
26.7 Series / Re: Fatal error: Uncaught Erro...
Last post by franco - September 04, 2026, 08:07:53 PMThis tells you which package you need to remove:
# pkg which usr/local/etc/php/ext-20-mongodb.ini
It's from an older PHP version and left over by Zenarmor indeed.
Cheers,
Franco
# pkg which usr/local/etc/php/ext-20-mongodb.ini
It's from an older PHP version and left over by Zenarmor indeed.
Cheers,
Franco
#9
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - September 04, 2026, 07:50:51 PMDanke sehr, meyergru!
What else I've tried but did not fix the issue:
1. I've temporarily disabled the "Renew DNS for Wireguard on stale connections" cron job.
2. I've temporarily replaced the short-ttl (1-5min) dynamic IP DNS entries with 60min CNAMEs pointing to them.
I somehow tie it all to the inbound Wireguard instance. I do not remember having had that issue before enabling inbound Wireguard. But, like stated, once I restart that instance after the OPNsense has (eventually) rebooted, it works perfectly until the next restart.
Quote from: meyergru on September 04, 2026, 10:17:56 AMWell, now I got you. I suspect this might be one of two cases:I have confirmed that both DNSmask and Unbound are listening to all interfaces, and that Unbound has the Default action: Allow. Nevertheless, there's an ACL entry, but that one should be rendered moot by the "default allow", supposedly. I have also tried disabling that ACL, confirmed that Unbound was still resolving (which makes sense, given the 'Allow' default action) - but even with the ACL disabled, "Configuring Wireguard" took minutes when rebooting, and resulted in WG clients unable to resolved until the WG instance was restarted.
1. You have bound your DNSmasq or Unbound to specific interfaces. In that case, when Unbound starts up, the WG interface does not yet exist and cannot be bound. You can test if this is the case by "sockstat -4 -6 -l | grep :53" and looking at which interfaces WG listens on when your error condition exists. If that is the case, you can avoid it by using "ALL" (nor no) interfaces to have the DNS service bind to 0.0.0.0. This is explained often throughout the forum: do not bind any services to specific interfaces. Besides, this is here: https://forum.opnsense.org/index.php?topic=42985.0, point 32.
Quote from: meyergru on September 04, 2026, 10:17:56 AM2. If you are using Unbound, there is another known possibility: the automatically generated ACL for the WireGuard network may be missing after boot because the WG interface does not yet exist when the Unbound configuration is generated.Would all this section apply, since I do NOT have to restart Unbound to make it all work? As mentioned above, I have even tried restarting Unbound, but this did NOT fix the resolution issues for WG clients - the only thing that does is restarting that WG inbound instance.
This has been reported before:
https://github.com/opnsense/core/issues/4142
Check /var/unbound/access_lists.conf while the problem exists and see whether your WG subnet is present. If it only appears after restarting Unbound, that is the cause.
Unlike the interface binding problem, the simple workaround here is to add an explicit ACL for the WireGuard client network under Services -> Unbound DNS -> Access Lists instead of relying on the automatically generated interface ACL.
This second case should only matter if your Unbound ACL default action is set to Deny or Refuse. With the default action set to Allow, the automatically generated interface ACL should be irrelevant (see: https://forum.opnsense.org/index.php?topic=42985.0, point 0). The old ticket was created when there where specific interface rules created (namely, in 2020).
What else I've tried but did not fix the issue:
1. I've temporarily disabled the "Renew DNS for Wireguard on stale connections" cron job.
2. I've temporarily replaced the short-ttl (1-5min) dynamic IP DNS entries with 60min CNAMEs pointing to them.
I somehow tie it all to the inbound Wireguard instance. I do not remember having had that issue before enabling inbound Wireguard. But, like stated, once I restart that instance after the OPNsense has (eventually) rebooted, it works perfectly until the next restart.
#10
Tutorials and FAQs / Re: How to get IPv6 with custo...
Last post by gmanca - September 04, 2026, 07:49:32 PMThank you!
Yes, I was trying to use Unbound and there is a chance that might worked when I assumed it was ISP DNS. But when I tried Identity Association it did not work. It very well might have been user error like me not saving/reloading interface.
I appreciated the details your provided and that helped me getting DoT working as well. It seems the adage of "best way to find the correct answer is not to ask a question but to post the wrong answer" is true :)
Cheers!
Yes, I was trying to use Unbound and there is a chance that might worked when I assumed it was ISP DNS. But when I tried Identity Association it did not work. It very well might have been user error like me not saving/reloading interface.
I appreciated the details your provided and that helped me getting DoT working as well. It seems the adage of "best way to find the correct answer is not to ask a question but to post the wrong answer" is true :)
Cheers!
