DNSCrypt service had a red icon after scheduled reboot

[MrHappyHippo]

Hi everyone,

I recently configured a cron job to reboot my OPNsense firewall every 3 days.

After this morning's reboot, I noticed I had no internet connectivity. The DNSCrypt service had a red icon and wasn't running. I had to manually start DNSCrypt and then restart Unbound to restore DNS resolution.

I suspect the issue may have been related to IP assignment: the firewall might not have received an IPv6 address (or even an IPv4 address) immediately after reboot, which could have caused DNSCrypt to fail or exit. However, I couldn't find any logs indicating the process was killed or why it didn't start automatically.

My setup:

Destination NAT redirecting all LAN DNS traffic to Unbound
Unbound configured to forward queries to DNSCrypt

Questions:

Should DNSCrypt normally start automatically after reboot?
Is additional configuration needed to ensure the proper startup order?
Could this have been a one-time startup failure?
Is there a recommended way to ensure Unbound waits for DNSCrypt before starting?

Any tips or troubleshooting suggestions would be greatly appreciated.

Note: I've attached the relevant logs for reference. For some reason, the attachments are only visible when you are logged in. The reboot occurred at 4:00 AM, and I manually fixed the issue by restarting DNSCrypt and Unbound around 8:20 AM.

Service start order:

DNSCrypt starts at 04:01:23
Unbound starts at 04:01:24
Then Unbound starts again at 04:01:41

DNSCrypt wasn't fully ready when Unbound started:
Unbound depends on DNSCrypt upstream
Large DNSBL list load:
DNSBL module has 968,522 entries.

[MrHappyHippo]

I've added two more cron jobs that might serve as a workaround. I didn't see any errors in the logs, so my idea is to have these additional tasks run shortly after the system reboot:

4:00 AM System reboot
4:10 AM dnsycrpy-proxy restart
4:15 AM unbound restart

Hopefully, staggering these restarts will ensure the services come up cleanly. I'll monitor and see if this resolves the issues.

[ChelseyMoore]

Your workaround will probably help, but honestly it does sound more like a startup race condition than an actual DNSCrypt crash. Especially since manually restarting DNSCrypt and then Unbound immediately fixes everything.

I've seen similar behavior on OPNsense when services depending on WAN connectivity or IPv6 come up before interfaces are fully settled. DNSCrypt may technically "start" successfully, but fail to establish upstream connectivity during boot and end up in a half-dead state while Unbound happily starts forwarding to it.

The timing in your logs is suspiciously tight too. One second between DNSCrypt and Unbound startup is not much, especially with a huge DNSBL load and interface initialization still happening in parallel.

Your staggered cron workaround is actually pretty reasonable as a first step. Personally I'd also test whether disabling IPv6 temporarily changes the behavior, just to rule out delayed RA/DHCPv6 assignment causing DNSCrypt startup failures.

Another thing worth checking is whether the DNSCrypt plugin has proper service dependencies defined at all. Some plugins don't fully integrate with boot ordering and assume networking is already stable when rc starts them.