Troubleshooting client & server DNS resolution issues when using Unbound?

[guest15389]

Try to change the GW as I had noted about from the * to GW_WAN

[princ3ssa]

Hrm, well good catch and I'm sorry that slipped by but I'm seeing the same result it seems:

[guest15389]

I'm a bit confused how your interfaces are setup.

It looks like your traffic is going through the PIAUSEast Interface as I'm not sure what that is.

I'm assuming 10.10.10.6 is your Windows machine?

I usually turn on logging on all my rules when I'm testing so I can trap the rule that's blocking it if something is.

What does the network topology look like?

[princ3ssa]

So I have the internet coming from 192.168.137.1 into my isolated test OPNsense network. OPNsense is 192.168.1.1. The Windows machine (in the screenshot) is being assigned 192.168.1.104 and I have another linux peer that statically set to 192.168.1.20.

[guest15389]

So where does the machine here come from in the log?



What's 10.10.10.6? That looks to be trying to get DNS to 192.168.1.1

[princ3ssa]

I don't know. It doesn't exist as far as I can tell..... I've been wondering that myself and that subnet doesn't even exist anywhere in my topology anywhere else.... I can't help but think it must be somewhere outside of us-eastprivateinternetaccess.com, but that subnet is private and shouldn't show up like this from what I understand.... so yeah   

[guest15389]

So let's take a step back, if you just turn on logging for all the rules and filter on the Windows machine, you should see it in the logs.

I did that as an example for my laptop which is 192.168.1.99.

You can see the rule hit when I did a DNS lookup.



You can even just ping 192.168.1.1 and see if that drops as it should and try that way too.

[princ3ssa]

First, I just want to thank you for your patience and effort here. I was becoming frustrated and desperate after a long wait and your help and attention is just so nice.

So I went into each rule and turned on "Log packets that are handled by this rule" for ALL the rules, including the pre-existing ones.

I then simply pinged a couple times with the Windows client (192.168.1.104) in the filter:


I also did some more looking and found that 10.10.10.6 is from the ovpnc1 interface: "inet 10.10.10.6 --> 10.10.10.5 netmask 0xffffffff"

[guest15389]

Oh, I see the issue now.

Go back to your DNS rule and make the source port any as what normally happens is the client will any source port number, but the destination port is going to be 53.

I see on the DNS rule you have the source port set to 53, which would make it not work.

[princ3ssa]

OK yes, I see what you're saying since random ports are used from the client to connect to the server's 53. But sadly I still get a timeout:

[guest15389]

Just to validate, do you have a host not in that VPN list that can test and make sure Unbound is working and give you a response back? The logs indicate the hit is going through, but seems like either Unbound isn't running or there is an ACL issue with it.

[princ3ssa]

Yes, so as I mentioned earlier, I do have 192.168.1.20 which is a Linux system. I made sure that it was not in my "VPN_Recipients" list and I then tried a couple things that both worked. Here's what I did in Linux:


Here's the firewall live log output:

[guest15389]

So you have the 192.168.1.20 and the host you were having a problem with was the 192.168.1.104.

If you take 192.168.1.104 out of the VPN list and validate if it now works, that would ensure the host works normally before putting it in the VPN list.

You could also add 192.168.1.20 into the list and see if it still works for DNS as well.

[princ3ssa]

So first, I've taken 192.168.1.20 and put it in the alias list to receive the VPN and got the same results:









Windows then behaves just like the Linux computer when it is removed from the VPN_Recipients alias list:

[guest15389]

Your DNS rule still isn't firing based on the logs you've shared so something seems still not right with it.

Can you share that?