Unable to load OCSP response upon pfSense reboot
-
Hi, I am currently experiencing an issue where the pfSense WebGUI is unable to load the OCSP response upon reboot. The certificate that I am currently using is a LetsEncrypt certificate issued with acme package that has the OCSP Must Staple option set. Looking at the nginx error logs I can see that there is an issue with resolving the r3.o.lencr.org hostname.
2024/03/22 16:10:10 [warn] 38649#100253: "ssl_stapling" ignored, host not found in OCSP responder "r3.o.lencr.org" in the certificate "/var/etc/cert.crt"
However once pfSense has booted, under Diagnostics -> DNS Lookup, I am able to successfully resolve the hostname.
The current workaround would be to restart the WebGUI once pfSense has booted to solve the issue but I am curious to know why this issue happens. I have tried using remote DNS servers only instead of the local unbound resolver but the same issue persists. Setting a host override for r3.o.lencr.org did not work as well although I no longer get the error in nginx. Perhaps pfSense is trying the load the OCSP response before the WAN link is established?
-
If you add an external DNS server in System > General Setup as a test does it boot correctly?
-
Tried with the following settings but it still results in the same error upon reboot.
-
If you set the behaviour there to 'use remote servers', does that allow it?
It seems likely that otherwise it is trying to resolve it before Unbound has started and fails.
-
Setting it to use remote DNS servers only does not work as well.
-
Huh. So maybe it tries to resolve before it has connectivity. Where is the logs does that error appear at boot/?
-
The logs for nginx failing to resolve r3.o.lencr.org is located at /var/log/nginx/error.log
-
Sorry I meant where in time does it occur? Does the timestamp put it late in boot process?
I would expect it to be after most services have started.
-
The nginx error is logged at 20:49:02. Looking at my system logs, it does seem that the WAN link is up before the error happens.
-
Yes basically at the end of boot. After Unbound has started. Hmm
-
As a side note, I have HAproxy configured to load the OCSP response for my frontend as well. The system logs also show that it fails to resolve the hostname at 20:49:09
The cronjob that HAproxy configures to run every hour to update the OCSP response does successfully complete although this is well after pfsense has booted at 21:01:00
-
At that moment, unbound was opening shop, but wasn't ready to take orders. Hence the "Name does not resolve".
It isn't hard to create a slow starting unbound : you need pfBlockerng - do not use the Python mode for best (very slow) result - and use many DNSBL.
Now unbound needs minutes to start up, and all resolving will fail, until its done.Or : another reason, as unbound is interface trigger happy : if another interface comes up, like the VPN interface : unbound restarts .... and if haproxy was also starting also at that moment : bingo.
We all love them, these race conditions ^^ -
Hi Gertjan, I did try to configure pfSense to use remote DNS servers only but it still results in the same error. Wouldn't configuring pfSense to use remote DNS servers only avoid the the use of the local unbound resolver and hence those race conditions stated would not apply?
-
Yes I would certainly have thought so.
You should check that fqdn does actually resolve against all configured servers in Diag > DNS Lookup though.
-
DNS Lookup under Diagnostics does successfully resolve the r3.o.lencr.org FQDN.
This is using Google DNS with the option use remote DNS servers only. Could it be an issue with outbound NAT rules not loading before pfSense attempts to resolve the hostname? I am not too familiar on when the firewall rules are loaded during the boot up process.
-
Connections from the firewall itself should not need NAT. But it would be loaded by that point anyway.
