"Recent posts
#1
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by meyergru - Today at 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.
#2
26.7 Series / Re: Unbound stopps suddenly
Last post by franco - Today at 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
#3
26.7 Series / Re: Fatal error: Uncaught Erro...
Last post by franco - Today at 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
#4
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - Today at 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 Today at 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 Today at 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.
#5
Tutorials and FAQs / Re: How to get IPv6 with custo...
Last post by gmanca - Today at 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!
#6
26.1, 26,4 Series / Re: Fatal error: Uncaught Erro...
Last post by Patrick M. Hausen - Today at 06:28:54 PMQuote from: BigFreddy on Today at 02:16:44 PMI seen that post but the mentioned solution requires a second device to setup where I'm looking for something that could run directly on the same firewall itself and perhaps display S.M.A.R.T readings via the dashboard. I did further research online and had trouble finding such monitoring plugin, it's really strange why there is no third party plugin to achieve this, obviously I don't know the limitations around it but generally speaking, it's something that should be possible to do.
Tools to do this exist and they all require Docker. Also is your OPNsense your only device with an SSD which would benefit from monitoring the drive's health?
I mean, if your network consisted of a single LAN, a laptop, a printer, a tablet and a phone, you would probably be running a Fritzbox and not OPNsense? You don't have any virtualising host (hypervisor?). No leftover RasPi?
I can really recommend building yourself dedicated monitoring infrastructure and not running Upmtime Kuma, Scrutiny, Prometheus, Grafana, LibreNMS, Elastiflow ... on the firewall.
#7
General Discussion / Re: Installation Image availab...
Last post by franco - Today at 06:25:43 PMYou can find the business images here: https://opnsense-update.deciso.com/
Use your subscription key to few the contents of the mirror.
Cheers,
Franco
Use your subscription key to few the contents of the mirror.
Cheers,
Franco
#8
26.1, 26,4 Series / Re: Cron scheduled missing?
Last post by franco - Today at 06:16:08 PM"so you're probably not imagining it"
... seems like thing that AI would say. Just saying. ;)
... seems like thing that AI would say. Just saying. ;)
#9
26.1, 26,4 Series / Re: Fatal error: Uncaught Erro...
Last post by franco - Today at 06:15:08 PMAre you a bot? I am in a pickle here and need a cupcake recipe quickly.
#10
26.1, 26,4 Series / Re: NetBird Interface breaks b...
Last post by franco - Today at 06:14:17 PMNo was definitely a plugin shortcoming.
Cheers,
Franco
Cheers,
Franco
