DNS Resolver Forgot Some Settings After 2.3.3 Upgrade

TheNarc

I have two OpenVPN client connections configured on my pfSense machine and had it configured to route DNS queries through them. This was achieved by:

1. On the "System > General" page, I have no DNS servers configured, "DNS Server Override" is unchecked and "Disable DNS Forwarder" is checked.
2. On the "Services > DNS Resolver" page, I have selected (highlighted) only the two OpenVPN client interfaces in the "Outgoing Network Interfaces" box. "DNS Query Forwarding" is unchecked.

Before the upgrade to 2.3.3, this configuration worked and multiple DNS leak test sites passed with expected results (i.e. DNS queries were going through the VPN client connections). Following the 2.3.3 upgrade, the same tests showed that my ISP's DNS servers were being used for DNS queries.

The most interesting bit is that following the 2.3.3 upgrade, all the settings on the "Services > DNS Resolver" page looked unchanged. So all I did was click the "Save" button on that page and then the "Apply Changes" button that appeared following. After doing that, the DNS leak tests passed once again. So it's almost as if the upgrade process transparently defaulted some resolver settings (I'm guessing at least the default to use all interfaces to send queries to authoritative servers), but did not reflect these changes in the GUI.

I should also note that this occurred on two separate pfSense boxes that I maintain, so it was not an isolated incident. Since I was able to fix the problem just by re-saving the settings for the DNS resolver, this isn't a support request but rather a PSA. I looked into filing a bug report, but the bug reporting guidelines explicitly say to post to the forums first to discuss/confirm an issue beforehand.

TheNarc

It turns out this was not caused by the upgrade to 2.3.3, and is reproducible simply by rebooting the pfSense machine. I had the presence of mind to back up the configuration both before and after performing the "save and apply settings" step on the DNS Resolver configuration page that corrects the issue, but the diff between those two saved configurations showed nothing. So it doesn't seem like the saved configuration itself is being changed, but that parts of it are not being restored after a reboot, and require the explicit "save and apply settings" step to be loaded.

TheNarc

I can confirm that on my two pfSense machines, I observe a consistent failure to restore the saved "Outgoing Interfaces" settings for Unbound. I confirmed this by examining a diff of /var/unbound/unbound.conf immediately following a reboot and then after going to the "Services > DNS Resolver" page and clicking "Save" followed by "Apply Changes". The conf file immediately following a reboot had no "outgoing-interface" entries, which means it defaults to using all interfaces. The conf file after I did the "Save" and "Apply Changes" reflected my explicit outgoing interface settings, which is to only use my two ovpn client interfaces. I don't know whether this is a bug in Unbound itself (perhaps if the OpenVPN client connections don't establish quickly enough, Unbound will revert to its default of using all interfaces as outgoing interfaces?) or whether it's a bug in the way that pfSense applies saved settings on a reboot. But I wouldn't expect that pfSense would modify underlying conf files on every boot. For what it's worth, I've attached a screen capture of the relevant portion of the diff showing the unbound.conf file immediately following a reboot (left) versus after I go to the "Services > DNS Resolver" page and click "Save" followed by "Apply Changes" (right).

unbound_diff.png_thumb

doktornotor

The resolver cannot bind to non-existent interface. There are well known issues with race conditions with assigned OpenVPN interfaces on boot. Avoid it unless absolutely required.

TheNarc

Yeah I just found a bug related to exactly this and added information about my issue:
https://redmine.pfsense.org/issues/6186

I understand the problem, although I feel that unbound should probably just fail to start if it doesn't find the interfaces it's configured to use as opposed to reverting to its default of using all interfaces, in explicit violation of the user's configuration. It's not clear to me though whether that behavior is an unbound thing or a pfSense thing.