Wireguard interface DNS server setting overrides resolv.conf

[surly]

I've observed this in 21.1.5 and 21.1.6.  I was occasionally finding that local name resolution wasn't working on the firewall.  My first sign of trouble would be alerts that the UPS netclient could not reach the server (because its name didn't resolve).

In Systems -> Settings -> General I have three DNS servers for the local system: 127.0.0.1, 1.1.1.1 and 8.8.8.8.  These are populated in resolv.conf normally.

In VPN -> Wireguard -> Local -> {config for first instance} I had populated DNS Server with the local end of my Wireguard point-to-point network.  (I believe some guide or testing when I first set this up led me to do this).  I have two site-to-site WG tunnels.

For DNS I use unbound in recursive mode, with local DHCP record insertion, listening on all interfaces.

When Wireguard cycles (restarted, toggled on/off, tunnel re-establishes after some kind of WAN transition) resolv.conf will be overwritten with the single entry from the Wireguard config.  It appears that unbound is not binding or not responding on the WG interface so DNS resolution for the firewall itself begins failing.  Some functions may have been falling through to an Internet DNS server but local records did not resolve.  I can do further testing and documentation if requested.

I removed the DNS setting and this seems to have stopped.  When testing site-to-site tunnels and traffic, I do believe that the WG interface answered DNS queries from remote tunnel peers.

I'm not so sure that the WG DNS setting whose help text is "Set the interface specific DNS server." should override all nameservers in /etc/resolv.conf when the tunnel transitions.  Although, IMO unbound should have answered queries at that address based on the other settings I see.

The limits of my experience make me unsure whether this is a bug, or at least an opportunity to add another sentence to the help text pointing out to users that filling in the WG DNS config option will override all the system nameservers.   I would perhaps expect it to APPEND the nameserver to the existing list in resolv.conf when the interface comes up?

[franco]

The elaborate answer after countless posts regarding this issue is: "yes".

It is how WireGuard intended and coded it and we don't approve.


Cheers,
Franco

[surly]

OK understood.  I spent some time with google and the forum search and never hit anything quite describing my issue.  Sorry....  I guess the help text could mention this impact if nothing else?  I will leave this config option blank - so far so good.

Cheers

[franco]

We since hid the option under advanced. The sad truth is help text won't help the people who may not read and understand it (why should it break firewall connectivity one would argue) and there are a number of tutorials out there that describe pretty well how to configure clients and pinning DNS servers to fix Internet which is not really applicable to a firewall/router type setup.


Cheers,
Franco

[errored out]

The help text should be changed.  This has nothing to do with not understanding.  This has to do with not conveying the correct information.

"Set the interface specific DNS server." Means to set the IP address the interface will send requests to, NOT change the entire firewalls' DNS resolve IP address.

Something that states the IP address entered here WILL change the resolver address for the firewall itself.

Also, the documentation needs to have this added as it is critical to causing issues (which I spent days trying to figure out why DNS was not resolving alias; Why the firewall itself failed connectivity checks; Why I could not check for updates; and other issues!)

All that is stated
DNS - Refers to the DNS servers that the client should use for the tunnel - see note below
...
If the DNS server(s) specified are only accessible over the tunnel, or you want them to be accessed over the tunnel, make sure they are covered by the AllowedIPs


Where does it state the firewalls specified DNS IP address will be changed?

[Greelan]

I assume you are referring to Step 7 of this guide: https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-7-configure-the-wireguard-client ?

You will note that section relates to the CLIENT configuration, not OPNsense. When rewriting the guide, I very deliberately did not include any reference to specifying DNS in Step 2 of the guide, which is where OPNsense is being configured - for precisely the reason that it creates the issue discussed in this thread . In the fact the guide says leave settings at the default unless the guide specifies otherwise, and the default is for the DNS fields to be blank on OPNsense.

If you only specify the DNS on the client, OPNsense’s resolv.conf is not changed.

[franco]

The help text should be changed.  This has nothing to do with not understanding.  This has to do with not conveying the correct information.

We moved it to Advanced setting since. I don't disagree with improving the help text, but half the people don't read docs and the other half complains docs are not good enough.

I still believe the way WireGuard offers and handles this is silly. That's above all the things that we can do from here.


Cheers,
Franco

[errored out]

I assume you are referring to Step 7 of this guide: https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-7-configure-the-wireguard-client ?

You will note that section relates to the CLIENT configuration, not OPNsense. When rewriting the guide, I very deliberately did not include any reference to specifying DNS in Step 2 of the guide, which is where OPNsense is being configured - for precisely the reason that it creates the issue discussed in this thread . In the fact the guide says leave settings at the default unless the guide specifies otherwise, and the default is for the DNS fields to be blank on OPNsense.

That is exactly my point;  There is nothing for the "server" side saying that entering IP's on the local tab will overwrite the configured DNS IP for the firewall itself and break functionality. 

Telling users to leave as default is fine, but don't exclude important information.   Many users need a more complex configuration.  How can I rely on "just use the defaults" when the defaults will not work for my network?
We needed more complex configurations, how can users get that information?  The forum has information spread everywhere, and asking another user does not always get a response.  Not to mention, the information could be wrong.

We moved it to Advanced setting since. I don't disagree with improving the help text, but half the people don't read docs and the other half complains docs are not good enough.

Cheers,
Franco

I had this problem.  I read the DNS documentation and searched the forum for days.  Searching DNS, DNS-drypt, by error message, alias, dns resolving, resolving alias, DNS alias, and others.  This exactly shows the problem was not even related to the DNS the firewall used.  A simple 1 line warning / note is what could have save many people posting becoming upset, saying there is another bug, the software sucks, the documentation sucks,etc.

Reading the docs is one thing.  However, the larger point is still being missed.  There are warnings for other areas of the documentation. Why not put others where they will help avoid these issues? 

This was on that same page.

Warning
Do not re-use these example keys!


Why not just put another one?


Warning

DNS: Entering an IP Address for the DNS Server (local tab) WILL OVERWRITE THE DNS RESOLVER IP ADDRESS FOR THE FIREWALL ITSELF (may break DNS resolution).


Before it is said, everything can't be documented.  I understand that it is not feasible even for the largest for profit organizations.   The focus is placing additional important information only.  Such as notes, warnings, tips, that are seen on the pages were it is needed. 

[Greelan]

Hey, I am just a user like you, and decided to contribute to an open source project to help others. There is nothing to stop you from creating your own PR on GH to include additional disclosure in the help text or the docs if you feel that would be helpful to others too

[errored out]

I have, it's just frustrating when pointing out problems and getting shutdown.

Thank you for your hard work, I do mean this.  Helping, each other is great for the community. 

[chemlud]

...  I read the DNS documentation and searched the forum for days.  Searching DNS, DNS-drypt, by error message, alias, dns resolving, resolving alias, DNS alias, and others.  ...

Seriously? I did a Startpage search with "opnsense wireguard DNS problem" and the third hit is this here:

https://homenetworkguy.com/how-to/configure-wireguard-opnsense/

Besides the slightly retarded decision to choose 10.0.0.1/24 as the Wireguard tunnel net this how-to adequately addresses potential DNS issues.

if I add to the search terms

Code: [Select]

site:forum.opnsense.org
the second hit is your buddy, where mimugmail describes the situation correctly. It's not that hard... ;-)

[errored out]

Seriously? I did a Startpage search with "opnsense wireguard DNS problem" and the third hit is this here:

https://homenetworkguy.com/how-to/configure-wireguard-opnsense/

I said searched the forum, not the internet that is a world of difference.  Not to mention the fact it seems you mis-read my post.  I specifically stated that I was having issues with DNS and did not know why (so I only looked up issues related to DNS).  I mentioned nothing regarding wireguard, because, I was not aware wireguard caused this issue. 

So yes, it is obvious for you to say oh look at what I just found, when you know what is wrong.  And I specifically stated I had search the forum, this included.

site:forum.opnsense.org dns resolve
site:forum.opnsense.org "dns"
site:forum.opnsense.org dns "crypt"
site:forum.opnsense.org "resolve" "issue"
site:opnsense.org "alias"
site:opnsense.org dns -unbound
and other variations.

Make sure you understand what is going on before you insert your foot in your mouth.

[franco]

Make sure you understand what is going on before you insert your foot in your mouth.

Unfortunately, I need to remind you to be more considerate. I get that you want specific things from this forum, but if you don't get them please don't be angry at others for sharing their opinions on those subjects.


Cheers,
Franco

[errored out]

Seriously? I did a Startpage search with "opnsense wireguard DNS problem" and the third hit is this here:

https://homenetworkguy.com/how-to/configure-wireguard-opnsense/

...

if I add to the search terms

Code: [Select]

site:forum.opnsense.org

Pointing out something starting with "SERIOUSLY" is not just for your information, nor it is be polite.  This is attempting to put someone down. 

After stating I had searched the forum, and specified the exact terms used to search the forum previously, one can think this is another attempt to put someone down. 

If chemlud has stated, sorry to hear that.... or this is what I found under the terms.... or hey, have you looked at ..... That is being courteous. 

Interjecting assistance is more than welcome and should be encouraged.  When someone enters an ongoing thread and starts "helping"  by criticizing an individual for their attempts and failures to search, how is this being helpful? Not to mention the information was not specific to what was stated (I was discussing dns,  chemlud dissued wireguard)

Is it not the same as says " how is it you could not find what you were looking for (stupid)?  It was the 3 list on the search results".   

That is why I stated that. 
Putting someone down is not right nor should be condoned.  This is why I defend myself towards someone who is trying to do so.

I'm not angry.  I am providing a warning the same as you are.  It is not what is said, but how it is said.   If he continues to make such statements, he could anger someone who may not be understanding.