Messages

My questions are:

1. How can I remove the nextdns.conf file and why is it being created? I can "rm nextdns.conf" fine. However, about restart it appears again. I can't see it listed in the templates. I don't have anything mentioning nextdns in the following directories:

Code Select Expand

/usr/local/etc/unbound
/usr/local/opnsense/service/templates/OPNsense/Unbound/core/ (grep nextdns *.* returned nothing)
/var/unbound/conf.d/

OK so I've found the configuration file in /usr/local/etc/unbound.opnsense.d/nextdns.conf - is the proper way to remove it from Unbound startup then to simply rm it from that directory?

Unfortunately, the fix doesn't survive a reboot and for some reason the copied cert.pem file is removed from /etc/ssl/ (I'm not to familiar with FreeBSD). I also tried adding the following line to the crontab via crontab -e, however that won't work as it appears to be deleted from the crontab upon reboot as well. (it was added via root user)

Code Select Expand

@reboot cp /usr/local/etc/ssl/cert.pem /etc/ssl/cert.pem
I was thinking I could maybe put a startup script to run instead of adding it to the crontab but I'm not sure what would be deleted as well in that aspect. So for now having Unbound fail on restart / power on and then manually copying cert.pem will have to do until I'm able to remove the nexdns.conf file and set this up with the recommended method.

I found a "bug" that I wanted to post here as it may be a use case that wasn't tested as it's a bit old. Hopefully it could also help someone else if they have the same issue. When the custom options for Unbound were removed in 21.7 I used a config file for NextDNS to be able to forward my Unbound queries to NextDNS as my upstream resolver. (If you read this thread you probably already saw the problem!)

Code Select Expand

router:/var/unbound/etc # more nextdns.conf
server:
  tls-cert-bundle: "/etc/ssl/cert.pem"
  forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: IP1#MyConfigID.dns1.nextdns.io
    forward-addr: IP2#MyConfigID.dns2.nextdns.io
Yesterday I upgraded to OPNsense 24.7.11_2-amd64 and afterwards Unbound would not start. I want to say the upgrades thus far have always worked thanks for that! Upon inspection I saw the following error in Unbounds logs:

Code Select Expand

Error    unbound    Unable to open pipe. This is likely because Unbound isn't running.
So that line was unfortunately not too much help. Over the next few hours I thought it might be DNSBL due to the only other error I had below but that unfortunately wasn't it.

Code Select Expand

2024-12-30T06:30:50    Error    configd.py    [0b524d64-f2df-4652-b315-62c805b1db9a] Script action failed with Command '/usr/local/opnsense/scripts/unbound/wrapper.py -s ' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 78, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/opnsense/scripts/unbound/wrapper.py -s ' returned non-zero exit status 1.
I also tried removing the Register DHCP Static Mappings but that didn't work either. I also did try to reinstall Unbound based on this post [SOLVED] Unbound not starting which still gave me the same error. (Though I didn't move any config files)

After some research I found this thread which mentioned getting better error messages from the CLI. So I ssh'd there and found a much better error:

Code Select Expand

unbound -c /var/unbound/unbound.conf
[1735538100] unbound[82458:0] error: error in SSL_CTX verify crypto error:80000002:system library::No such file or directory
[1735538100] unbound[82458:0] error: and additionally crypto error:10000080:BIO routines::no such file
[1735538100] unbound[82458:0] error: and additionally crypto error:05880002:x509 certificate routines::system lib
[1735538100] unbound[82458:0] fatal error: could not set up connect SSL_CTX
I knew the custom forwarding was setup through a custom config file and thought that perhaps custom forwarding was no longer supported that way. So after a system restart with Unbound unable to start, I rm'd /var/unbound/etc/nextdns.conf successfully and was able to restart Unbound from the CLI successfully.

However, further troubleshooting found that nextdns.conf is continuously re-created somehow after the service restarting and/or system restarting. (It was late and I didn't track down the specifics for when it restarts.)

In my search I had read on this thread about the cert.pem file being moved and that was what I needed to figure a workaround out.

From the release notes:
o system: remove the SSL bundles in default locations

Is this unbound still using these SSL bundles?

With the nextdns.conf file being automatically re-created I couldn't update the location of the cert.pem file. So, as it was late I then figured I'd try the old school hack of copying the cert.pem file to the missing location from the nextdns.conf file:

Code Select Expand

cp /usr/local/etc/ssl/cert.pem /etc/ssl/cert.pem
Voila, Unbound will now start and I'm still able to use the custom forwarding I setup. Although I do realize I should update that to the fully supported way now. My questions are:

1. How can I remove the nextdns.conf file and why is it being created? I can "rm nextdns.conf" fine. However, about restart it appears again. I can't see it listed in the templates. I don't have anything mentioning nextdns in the following directories:

Code Select Expand

/usr/local/etc/unbound
/usr/local/opnsense/service/templates/OPNsense/Unbound/core/ (grep nextdns *.* returned nothing)
/var/unbound/conf.d/
2. Is the proper way to do custom fowarding for an upstream resolver then to use the Unbound DNS > DNS over TLS option?

3. Is there a way to get the errors that were seen running it in the CLI in the GUI? They were very helpful and yet I couldn't see them in the Unbound logs (log level 0), or in the General logs.

chbmb, thanks for the work on this one. It helped me get it setup. I have a few suggestions specifically for your blog. Thanks for all the hard work!

• Can you add more depth to the "Add Wireguard Interface" section? There's a lot of options that are glossed over.
  
  
• Can you do screenshot for adding the Wireguard interface?
  
  
• "add a new interface, selecting wg0", I'm not sure where to do that? wg0 wasn't mentioned elsewhere in the guide and when you click the Add button then one is automatically created.
  
  
• Do you have to setup a network for your new interface and dhcp etc? (You don't, but just maybe mentioning that would be good for new comers).
  
  
• Can you mention that the WireGuard service needs to be enabled from the main page via VPN > WireGuard. In the official document they mention "Now we can Enable the VPN in tab General and continue with the setup.".
  
  
• Explain this: "Redirect target IP Enter the LAN IP address of your OPNsense install | We want the traffic to reach the WireGuard tunnel on OPNSense" if you're any good at drawing, an example would be great. Maybe explaining how the traffic will flow.
  
  

Hi, thanks for this guide, it was quite helpful. I used it as well as the original to get this going for myself. It wasn't quite straight forward though, so I'm replying here with some info so hopefully both guides can be updated.

• The public key needs to be entered for both local and endpoint. If you save either endpoint / local without entering it for both the WireGuard service will be unable to start.
  
  To troubleshoot from the CLI just run the command to start the WireGuard service and read the error message: /usr/local/etc/rc.d/wireguard start
  
  Bug? In the VPN > WireGuard > General page, enabled is checked even if service isn't running, this should be fixed to perhaps keep the check but display the error message from the CLI above if the service didn't start up correctly? This one had me scratching my head for a while.
  
  
• DNS needs to be setup for the new WG interface or whatever you called the new interface you created. Go to Services > Unbound DNS > General > Network interfaces and select WG.
  Note: If the service is NOT running, you will NOT have the ability to add a new interface for WireGuard from the Interfaces menu.
  
  Note: This is NOT the WireGuard interface that is automatically created.
  
  
• You need to create an incoming and outgoing IPv4 rule on the WG interface. You can restrict from there once it's working.
  
  
• The rule created for WAN rule added to WAN is was created at the bottom so wouldn't allow traffic through. You need to ensure it's above any block rules. (I have default block everything rules at the bottom of my rule list for each interface.)
  
  
• Please ensure that after the connection is setup the first time, for any additional changes within a sub screen of the WireGuard page i.e an local or endpoint page, you need to hit Save at the bottom of the page that lists all locals or endpoints since that restarts the service.
  
  
• I'm not sure when setting up the local, if it matters if the network is listed as 192.168.1.0/24 or 192.168.1.1/24 as the official doc and this one differ on that point.

Question: Will this setup cause any issues with setting up Dynamic DNS? On the DDNS creation page it says:

"You must configure a DNS server in System: General setup or allow the DNS server list to be overridden by DHCP/PPP on WAN for dynamic DNS updates to work."

But with this setup both of those are not done.

At least with Namecheap Dynamic DNS this works.

Question: Will this setup cause any issues with setting up Dynamic DNS? On the DDNS creation page it says:

"You must configure a DNS server in System: General setup or allow the DNS server list to be overridden by DHCP/PPP on WAN for dynamic DNS updates to work."

But with this setup both of those are not done.

Then it's surely an error at Cloudfare not detecting it as encrypted ...

That's what I'm thinking, I just wanted to check to make sure I didn't have any settings wrong though.

are you using pihole by any chance?
I have the same issue.

No, I'm just using the settings from the first post here that use Unbound as a forwarder to DNScrypt which then uses DNS over HTTPS to Cloudflare (in my case) to resolve.

Can you check with tcpdump on WAN If you see DNS traffic on 53 or just 443.

Ya, I did that earlier, nothing on 53, although I also have a firewall rule blocking it for external networks and only allowing it for internal.

Code Select Expand


tcpdump -ni ix0 port 53
listening on ix0
0 packets captured
130285 packets received by filter
0 packets dropped by kernel

tcpdump -ni ix0 port 443
listening on ix0
3109 packets captured
2318077 packets received by filter
0 packets dropped by kernel

...
11:00:31.179125 IP 1.0.0.1:443 > WAN_IP:17505: flags [.] ack 18163, win 63, length 0
11:00:31.179377 IP 1.0.0.1:443 > WAN_IP:17505: flags [F.] seq 53635, ack 18162, win 63, length 0


tcpdump -ni ix0 host 1.0.0.1 and port 443 - I get a whole bunch more 1.0.0.1:443 traffic.

Unbound settings:

Code Select Expand


Network interfaces: All local ones
CheckDNSSec Support
Check DHCP Registration
Check DHCP Static Mappings
Local Zone Type: Transparent
Outgoing Network Interfaces: All local ones
- Note I had this set to WAN when I was using pfSense but it doesn't work for me here

do-not-query-localhost: no

forward-zone:
   name: "."
   forward-addr: 127.0.0.1@5353


Can you check the logs after dnscrypt-proxy restart if there is something interesting?

Nothing that I could see:

Code Select Expand


[2019-12-08 08:53:59] [NOTICE] dnscrypt-proxy is ready - live servers: 1
[2019-12-08 08:53:59] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 3ms)
[2019-12-08 08:53:59] [NOTICE] [cloudflare] OK (DoH) - rtt: 3ms
[2019-12-08 08:53:59] [NOTICE] Now listening to 127.0.0.1:5353 [TCP]
[2019-12-08 08:53:59] [NOTICE] Now listening to 127.0.0.1:5353 [UDP]
[2019-12-08 08:53:59] [NOTICE] Loading the set of forwarding rules from [forwarding-rules.txt]
[2019-12-08 08:53:59] [NOTICE] Loading the set of cloaking rules from [cloaking-rules.txt]
[2019-12-08 08:53:57] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-12-08 08:53:57] [NOTICE] Firefox workaround initialized
[2019-12-08 08:53:57] [NOTICE] Loading the set of whitelisting rules from [whitelist.txt]
[2019-12-08 08:53:57] [NOTICE] Source [public-resolvers.md] loaded
[2019-12-08 08:53:57] [NOTICE] Network connectivity detected
[2019-12-08 08:53:57] [NOTICE] dnscrypt-proxy 2.0.31
[2019-12-08 08:23:19] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 4ms)


When I visit https://1.1.1.1/help in Firefox (Note I have uBlock Origin installed), I also get the same message from Edge though about DoH not working.

Code Select Expand


[2019-12-08 09:00:48] 192.168.1.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.0.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.0.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net DS PASS 9ms cloudflare
[2019-12-08 09:00:48] 192.168.3.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net A PASS 4ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net A PASS 4ms cloudflare
[2019-12-08 09:00:48] 192.168.9.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.map.cloudflareresolve.com A PASS 10ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.map.cloudflareresolve.com A PASS 33ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.1.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.1.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.9.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-doh.cloudflareresolve.com A PASS 6ms cloudflare
[2019-12-08 09:00:48] 192.168.3.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-dot.cloudflareresolve.com A PASS 7ms cloudflare
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-dot.cloudflareresolve.com A PASS 34ms cloudflare
[2019-12-08 09:00:48] 192.168.2.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-cf.cloudflareresolve.com A PASS 77ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 is-cf.cloudflareresolve.com DS PASS 2ms -
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-cf.cloudflareresolve.com A PASS 19ms cloudflare


I've setup everything in this guide. It's worked great and appears to be doing it's job. I've selected only Cloudflare for my DNScrypt provider. However, when I go to Cloudflare's help page it shows me that I'm not connected and DNS over HTTPS isn't working. I was wondering if you might know why?

I use the 1.1.1.1 test page: https://1.1.1.1/help/