I Can't Forward to My Local DNS Server

Started by FAT32, January 05, 2024, 11:24:26 PM

Previous topic - Next topic
I have a local DNS before I installed OPNSense. I want to forward all requests that are going to OPNSense to go that server. I tried many ways to do that.

I created a NAT rule where it looks for all requests that are NOT originating from the DNS server and forwards the packet to the DNS server. But that causes a timeout for some reason. I can't even see the connection on the live view on the firewall being made.

I tried to use unbound as a forwarder and gone to services->unbound DNS->forward queries and put an entry with an empty domain. It says that it should forward all queries to the specified server but it's as if nothing happened. Although here I can see a connection being made on the firewall. It's just that the names that I set on the server are not being resolved for some reason. Other names are OK like kernel.org and other external domains.

I tried to put in the DNS server on system->settings->general and enabled DNSMasq but that didn't work either. Same as unbound.

Any ideas on how I can fix that?

The NAT rule needs to look instead for all requests NOT destined to the OPNSense interface you have facing the server ie. the LAN to be redirected to your DNS server. TCP and UPD, keep DNS port from dropdowns both on destination port range and redirect target port.
Keep the default "Add associated filter rule" if you haven't changed defaults for rule association, so that one is created automatically.
By doing it this way, you are saying, DNS queries sent to OPN (by default is the interface where you have DHCP sending this interface as the DNS server to clients) on port 53, forward them to my server.

The NAT rule is like this now

Interface: LAN
Protocol: TCP/UDP
Source / Invert: Yes
Source: ! dns_server
Source Port Range: any
Destination / Invert: yes
Destination: ! dns_server
Destination Port Range: dns
Redirect target IP: dns_server
Redirect target port: DNS
Pool Options: Default
Filter rule association: Add associated rule

It still doesn't work. I think something is wrong with my NAT configuration or something. I tried another rule to forward everything that was destined to a random unused IP to my webserver. But nothing happens when I try it.

Interface: LAN
Protocol: TCP/UDP
Source / Invert: No
Source: any
Source Port Range: any
Destination / Invert: no
Destination: unused_random_ip
Destination Port Range: HTTP
Redirect target IP: web_server
Redirect target port: HTTP
Pool Options: Default
Filter rule association: Add associated rule

Applied and nothing happens when I put in the IP on the browser http://unused_ip. It just times out.


I have followed the article to a tee before but it's still not working :(

best thing then is to post your rules and explain how you are testing.

This is the DNS rule

Interface: LAN
Protocol: TCP/UDP
Source / Invert: Yes
Source: ! dns_server
Source Port Range: any
Destination / Invert: yes
Destination: ! dns_server
Destination Port Range: dns
Redirect target IP: dns_server
Redirect target port: DNS
Pool Options: Default
Filter rule association: Add associated rule

I that a good format for the rule? If you have a way for me to export the rule into text I can do that instead or post a screenshot. I tested the rule by doing the command nslookup on my machine and specifying the gateway as my nameserver like this
nslookup my.local.domain 192.1681.1
I was first looking at the firewall live log but it was showing nothing when I chose "action is nat" so I used wireshark instead. I will attach a screenshot with the result of the nslookup command and it does show that the device then started talking to the dns server but this is the result of the command
$ nslookup my.local.page 192.168.1.1
;; communications error to 192.168.1.1#53: timed out
;; communications error to 192.168.1.1#53: timed out
;; communications error to 192.168.1.1#53: timed out
;; no servers could be reached


I have another rule to test for something like HTTP and it's the exact same. The rule is
Interface: LAN
Protocol: TCP/UDP
Source / Invert: No
Source: any
Source Port Range: any
Destination / Invert: no
Destination: unused_random_ip
Destination Port Range: HTTP
Redirect target IP: web_server
Redirect target port: HTTP
Pool Options: Default
Filter rule association: Add associated rule

The exact same thing happens where it says that the connection cannot be made.

Yes this is good format.
Since your goal is "I have a local DNS before I installed OPNSense. I want to forward all requests that are going to OPNSense to go that server.", then your rule is instead:

Interface: LAN
Protocol: TCP/UDP
These advanced source options you don't need to alter from defaults:
---
Source / Invert: No
Source: LAN_net
Source Port Range: DNS
----
Destination / Invert: yes
Destination: LAN address
Destination Port Range: dns
Redirect target IP: dns_server
Redirect target port: DNS
Pool Options: Default
Filter rule association: Add associated rule

I suggest delete the current rule and create a new one and don't change defaults on source. You have a problem there at source port DNS. That port is only to be defined as destination port.
So your rule will phrase as: dns queries FROM the LAN network, not going to the LAN address, with a destination of DNS port, redirect it to your dns server on the dns port.

I tried that and unfortunately it doesn't work. I don't think that the issue is the NAT but something else. Because from wireshark, I can see that the clients are being redirected to the correct nameserver but the problem is that they all hang for some reason.

As for the source address, I did that because the NAT would redirect the nameserver to itself so it can't try to resolve something that it's not authoritative on. So I can't really keep it at the default.

Clients ask some name server, OPNsense redirects the packet to your designated resolver. If that system is also connected to LAN, it will answer the client directly.

The client will ignore the answer because it's from a server it did not ask in the first place.

So you must NAT your client addresses somehow, so the replies go back to OPNsense which will then answer the client with a correct source address.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Additionally, this rule is to force clients not respecting what dns server they were assigned by the DHCP lease, or that might be having a static ip, or even rogue devices with hardcoded ones.
And maybe I misunderstand as well. I assumed "your own dns server" was something like a pihole or adguardhome that can be your recursive resolver that goes out to the root servers.
Maybe use this resource https://homenetworkguy.com/how-to/redirect-all-dns-requests-to-local-dns-resolver/
If we need to look at this again, I suggest we go back to very basics with networks, interfaces, ip addresses, etc. for your whole setup. Diagrams would be handy too.

IT WAS REBIND PROTECTION THE WHOLE TIME

ANSWER:
I just used UnboundDNS and went to services -> unbound -> advanced -> Rebind protection networks

I removed the entry where it says 192.168.0.0/16. This solved the issue and there is no need to muck with the firewall rules or anything like that.

I looked at the possible settings on DNSmasq and there is no configuration for rebind protection. And I know for a fact that it does enforce some protection since there was a log entry that mentioned

Warning   dnsmasq   possible DNS-rebind attack detected: my.domain

I think if you're really determined to solve it on DNSmasq, you can ssh and change the configuration files directly.

MY LIFE'S STORY:
I was trying for so long to get Unbound and DNSmasq to forward but they both were blocking answers to my local network. The main reason that I even had the local DNS server is to resolve my local services to my local servers. This makes everything much smoother for example, on my phone. But I think that the default is to block answers to local addresses so that no one intercepts the local DNS server and forwards to a man-in-the-middle. I think that it's a crazy idea unless you have a public network accessible to anyone. But on OPNSense, you have all of the control on the LAN and if someone somehow intercepts your DNS queries in the LAN, you're already toast. But that's just me. I hope this helps someone else.

we also have the same problem, will be testing your solution this weekend.
thanks

Ah, makes sense.
It seems Unbound has that additional option but if dnsmasq doesn't on the OPN UI, you could disable it globally from System->Settings->Administration.

Quote from: Patrick M. Hausen on January 08, 2024, 02:27:35 PM
Clients ask some name server, OPNsense redirects the packet to your designated resolver. If that system is also connected to LAN, it will answer the client directly.

The client will ignore the answer because it's from a server it did not ask in the first place.

So you must NAT your client addresses somehow, so the replies go back to OPNsense which will then answer the client with a correct source address.

I have added an outbound NAT rule to get this to work

Interface:  LAN
Destination Port: 53
NAT Address: Interface Address