Troubleshooting client & server DNS resolution issues when using Unbound?

[princ3ssa]

I started a thread on Reddit and thought perhaps I should bring it over to the forum for further discussion.

I don't really want to repeat my initial remarks from Reddit here, so I figure I'll summarize the most salient points (unless someone would like for me to pull everything into this).

As indicated, I'm following this guide for pfSense (but it's been nearly a one-to-one translation so kudos to you guys for keeping things so clearly similar while improving the UI!!) and have gotten stuck with DNS issues, specifically in STEP 11.

I'm on OPNsense 19.1.5_1-amd64 and using Unbound (Dnsmasq is disabled) and I have verbosity set to level 3 for Unbound. I'm able to watch the Unbound logs with "clog -f /var/log/resolver.log".

I have OPNsense set up in an isolated test network with 2 clients attached (1 Windows 10 with DHCP & 1 Linux with a static IP). OPNsense is running at 192.168.1.1. The Windows and Linux clients are both able to ping OPNsense AND 8.8.8.8 (so traffic is fine both locally and out to the internet). When I assign DNS manually to either client (8.8.8.8 ) they can resolve hostnames fine and browse the web, but when 192.16.1.1 (OPNsense) is used as the DNS server on either system, no name resolution occurs.

There are no updates in resolver.log when websites are visited or name queries should be made.

I found that when I do "telnet 8.8.8.8 53" I am able to get a response (well it hangs up on me since it needs a binary understanding client vs telnet), but when I do this for OPNsense ("telnet 192.168.1.1 53") it times out and there is nothing within the resolver.log.

I don't know all the fields in /var/log/filter.log, but saw that filter.log was being updated pretty quickly and so I filtered for "53" ("clog -f /var/log/filter.log | grep 53") and saw this:



Each of the 3 longer lines there is a time I did "telnet 192.168.1.1 53".

I have to think there's some kind of firewall or some other issue blocking Unbound (port 53) from replying..... What could be going on?

[guest15389]

DNS uses UDP normally and not TCP so you can't telnet to a UDP port.

As I noted in the other post, you need to allow Unbound on your OpenVPN Interface if you want it to work and make sure the network has access to it.

https://imgur.com/JAZzrSJ

[princ3ssa]

I thought you were saying to enable it on Network Interfaces from your other reply:


But from your screenshot it seems you meant to go to Services > Unbound DNS > Access Lists. This is very confusing since this is not a VPN with a known IP address (not even a known subnet), but rather a privacy VPN (like Private Internet Access or PIA) functioning with various VPN nodes and various name servers around the world.

This is why the other pfSense guide is more pertinent and nearly spot on except for this one particular DNS issue so far it seems. Up to this step (Step 11, Method 2 of 12 steps) this has gone relatively smoothly and it's amazing at how direct the interfaces correlate except for a few relatively minor quirks. This one probably isn't a big deal either if I can just figure out what's going on here and understand how to implement this proper access or maybe interface listening.

If I try "nc -uv 192.168.1.1 53" I do get "Connection to 192.168.1.1 53 port [udp/domain] succeeded!" and firewall traffic appears:


It also looks like from the Unbound log that something did happen there when I ran netcat:


So I guess I am not understanding something correctly like you're saying with the VPN access and then how to deal with Access Lists....

[guest15389]

I still am not following what you are trying to do.

If you want to setup PIA for VPN for clients, you normally would push PIA's VPN to your clients so you don't 'leak' any DNS information and everything is contained.

If you want your PIA clients to resolve using your local DNS (DNSMasq or Unbound), you can point to that, but you need to make sure those clients have access.

That guide is fairly dated and seems to be missing some steps.

PIA has their own guide for pfSense which would be a better starting point.

https://www.privateinternetaccess.com/helpdesk/guides/routers/pfsense/pfsense-2-4-3-setup-guide

as that routes all traffic through.

Routing certain clients through takes a bit more effort as there a number of post relating to that on the pfSense forums.

If you hit search on the forums here, you found hits on how to do that on OPN.

https://forum.opnsense.org/index.php?topic=8998.0

[princ3ssa]

No, I do not want to forward that information to clients, but instead want to use the method outlined in the pfSense document that many PIA users are also interested in. The people who do use pfSense right now are thrilled with the results and even one has expressed interest in moving to OPNsense.

Their (PIA's) pfSense guide had some problems and I have been in touch with support about this and hope they fix the guide.

The idea is to use load balancing in order to provide a few to several connections to their network that will then augment speed. One user, for example, who uses pfSense and that guide has seen their download speeds for everything from Windows updates to multi-threaded web downloads and even Netflix go from under 100 Mbps to over 500 Mbps. It seems that PIA has been having trouble with ISPs and otherwise and can't provide much more than 50-100 Mbps for many users now on a single VPN connection. Again, by using load balancing these limitations are able to be mitigated.

So in my particular case right now and where I'm having trouble (the guide has been fantastic and OPNsense has been very cooperative with a few minor tweaks) is on the STEP 11, METHOD 2 for "LEAK PREVENTION" (for this reason: "...or you still want to be able to resolve DNS addresses in the event that the VPN server you specified in Method 1 goes offline. The port forward method I showed in Method 1 cannot be load-balanced across multiple VPN gateways so if the one you decide to use for it were to be down you wouldn't be able to resolve any domain names, essentially limiting your internet access.") Here are the instructions that are causing me trouble:

[guest15389]

I read through the guide and from what I'm reading, if you are using method 2, you are using the local OPN resolver at 192.168.1.1 and it's being let out via the VPN gateways and not the normal internet gateway.

You can test directly from a client.

Code Select Expand

nslookup
> server 192.168.1.1
Default server: 192.168.1.1
Address: 192.168.1.1#53
> google.com
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: google.com
Address: 172.217.6.238

If you aren't able to resolve, you are missing a rule letting the clients to your firewall.

Multiple VPNs or connections really don't do much for speed other than perhaps mitigate peering issues. In most cases, it can make things worse if the VPN providers are slow too. I only use the VPN to mask traffic.

[princ3ssa]

Alright, I'm getting:

Code Select Expand


$ nslookup
> server 192.168.1.1
Default server: 192.168.1.1
Address 192.168.1.1#53
> google.com
;; connection timed out; no servers could be reached


Therefore this indicates that I'm missing a rule letting the clients to (or through?) the firewall....

So does this mean I need to add a rule to the Firewall? Or add an Access List? It seems you must mean that the client system cannot penetrate the firewall of OPNsense because it's blocking access.

These rules are also set up as explained in the guide. Here's what I have:


My rules are set up as per STEP 8 in the guide.

Here are the details of these 2 active rules I set up from that (In order as they appear above. Please scroll to the right as they are side by side):


(As a side note HTTP pipelining and various download speedup opportunities today, aside from peering, are why people are saying that the converse is happening - this load balancing will greatly speed up networking when used in conjunction with a VPN like PIA.)

[chemlud]

The clients don't "penetrate" the opnsense for DNS, they contact Unbound on port 53 and this service does the DNS stuff and hands back the results to the client.

Allow on LAN (your first rule) access to port 53 of the sense (LANadress), so: add port 53 to your first rule in the LAN screenshot of your last post and report what the DNS lookup gives you...

[guest15389]

Yeah, you need a rule from your VPN_Recipients to access your local firewall on UDP 53 via the GW_WAN so you can resolve DNS on from 192.168.1.1.

That rule should go above your VPN_Recipients / Domains to Bypass rule.

You should be able to test DNS resolution on a IP that isn't in your VPN_Recipients to validate DNS is working as that should be covered by the second the last rule in your screenshot that allows LAN traffic to everything although that seems to be using the default GW so that may need to be tweaked to use the GW_WAN to not go out the VPN GWs.

[princ3ssa]

Oh @chemlud I think I overlooked this because it is the "Anti-Lockout Rule" and I never even thought about modifying it.

When I click on it, it redirects me to Firewall > Settings > Advanced and unfortunately there doesn't appear to be any settings here to control the port number. Is there something I am overlooking that would allow me to edit this? Or should I simply allow being locked out in order to get rid of this first automatic rule altogether?

If I do need to eliminate automatic rules such as this anti-lockout, should I create additional rules? And if so, can you give some explicit settings? I can give some examples of why this is a problem right now for me, but I figure I should wait to hear back first before I go any further.

[guest15389]

Sorry as I don't think modifying the anti lockout rule is the right thing to do as that's there for a different reason. I thought I shared some specific steps to add a DNS rule, but good luck.

[chemlud]

Add a new rule and place below the anit lock-out rule with port 53 and LANaddress as target (source: at least your VPN clients).

[princ3ssa]

Oh! @Animosity022 you're saying to add a rule while @chemlud was saying to modify the rule. I don't see a way to modify or even eliminate the Anti-Lockout Rule so I guess your (@Animosity022's) method is the only workable (and preferred) method.

When I go to create a rule, I think you mean these settings right? But when I do this I get a "not allowed" on the "Destination port range" (and even on the Source port range if I expand it with the advanced button):

[guest15389]

Change the protocol from any to TCP/UDP and use port 53 to 53.

[princ3ssa]

OK, so I have this for the specific settings:


I applied moved the rule just below the Anti-Lockout Rule and applied the update:


Verified that the IP I'm working from is in the VPN_Recipients Aliases list.

Did the lookup and got ";; connection timed out; no servers could be reached" again.

Looked at the firewall log and not really seeing anything indicating this rule is being hit (.104 is the Windows system that has the DHCP lease that I'm using to test nslookup with here):