Bug #13542


Boot delay caused when OpenVPN config uses alias list that relies on DNS

Added by Adrien Carlyle 2 months ago. Updated about 2 months ago.

DNS Resolver
Target version:
Start date:
Due date:
% Done:


Estimated time:
Release Notes:
Affected Plus Version:
Affected Architecture:


pfSense+ 22.05 in Azure

I use OpenVPN with an alias list that includes 76 (and growing) FQDNs.

When the system is set to internal DNS with public fallback, the system hangs for 10+ minutes at boot at "Syncing OpenVPN settings", I assume this is because each record lookup fails and has to time out before it is resolved via public DNS.

Changing this option to public DNS only works around the issue, but there are some cases where I need the firewall to use internal DNS so work with domain overrides.

Perhaps the resolver could be brought online just after WAN is established, or the fallback behavior could be tweaked so that it falls back for an entire alias list instead of each individual entry (since tables are refreshed periodically anyway)

Actions #1

Updated by Kris Phillips about 2 months ago

This doesn't sound like a bug, as the issue is not present when using different DNS servers based on the original report. This sounds like an issue with DNS Rebinding or something similar.

Please clarify what you mean by "FQDNs" in OpenVPN.

Actions #2

Updated by Adrien Carlyle about 2 months ago

In the OpenVPN server configuration option "IPv4 Local network(s)" I use an alias that contains FQDN hostnames like etc.

I worked with Netgate support to narrow this issue down. A asked them if I should create a bug for this and was told to proceed.

This is a bug because OpenVPN is started before the resolver service which causes the lookup failures/fallbacks when using pfSense's default DNS resolution behavior. If the resolver is online earlier in the bootup sequence OpenVPN comes online instantly (which I have proven by manually starting the resolver while OpenVPN is hung).

If the startup order can't be changed so that the resolver is online before OpenVPN, then the DNS fallback to public servers should be modified during bootup so that it only falls back once during the entire startup sequence.

I haven't tested what happens if I tell the firewall to use internal only DNS and reboot it. My guess right now is that the table would be missing all DNS based entries an boot and would fill in the missing entries when the alias list is refreshed.

Actions #3

Updated by Adrien Carlyle about 2 months ago

I just realized you were confused by what I was referring to in my workaround.

I meant that if I change the setting:
System -> General -> DNS Resolution behavior

From: Use Local DNS, fall back to remote DNS

To: Use Remote DNS servers, ignore local DNS

Everything boots up normally because pfSense uses remote DNS and doesn't depend on the resolver.


Also available in: Atom PDF