Redirecting LAN DNS
-
I would like to redirect all DNS requests on the LAN to a specific DNS server 100.96.1.1.
I have followed this guide:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.htmlThe guide contains the following which I do not understand
My NAT now looks like:
Workstation DNS requests to not appear to redirected:
-
@McMurphy didn't we just go over how your queries need to be fully qualified?
And redirecting dot is not going to work.. Not if the dot client is actually doing what it is suppose to do and validate the they are talking to the correct dot server.
Also why are you redirecting to cgnat IP? even if nslookup added your search suffix.. Are you using cgnat space internally?
Did you validate that this 100.96.1.1 can even resolve your fqdn?
Do a directed query to this 100.96.1.1 with your fqdn, does it respond?
-
The same outcome if I add the domain name to the hostname.
The hostname can be resolved when I specify the DNS server manually.
-
@McMurphy what Ip is what here.. is 192.168.2.254 your lan address? Or some IP on some other network, if your network is 192.168.2 and .254 is not pfsense IP, why would it be sending it to pfsense?
Also you didn't follow the guide, because the guide is redirecting to loopback, 127.0.0.1 - there are all kinds of odd stuff that can happen when you redirect to some other IP that is not pfsense. Client might get a response from some other IP vs pfsense and not take the response anyway.
Anywho.. Here created a redirection, works just fine. There is no freaking way 1.2.3.4, which doesn't even do dns would be able to resolve my local resource.. So clearly it was redirect ;)
-
pfSense: 192.168.2.254
I tried to adapt the guide to what I wanted. Following what is in the green box I get:
I can't use the pfSense DNS as I need to ensure all queries are resolved by 100.96.1.1 (DNS filtering service) so I am looking for an alternative.
-
@McMurphy
Are you behind CGNAT?
Since your DNS is in the RFC6598
100.64.0.0 - 100.127.255.255Why not put some other DNS servers in the "General Setup"
Are you ISP blocking you for using other DNS servers?Or, maybe this one is blocking you?
-
@McMurphy you show your port forward where are you firewall rules on the interface?
So you want this 100.96.1.1 to resolve all your external dns then? Just forward to it. And block all your other dns..
Now that your saying hey anything but 100.96.1.1 forward to loopback, does unbound forward to this 100.96?
In your previous example if pfsense is 192.168.2.254, that would be the lan address. So your ! lan address wouldn't have applied..
100.96 as @MoonKnight is pointing out is cgnat - seems like an odd dns to use that filters, since the only way to talk to that IP would be on the isp network that is using that cgnat..
Also if your forwarding to this 100.96 address, and it sends back rfc1918, that 192.168.1.12 that would be a rebind, and no psfense would hand you that address unless you turned off rebind protection for that domain. Which is why a directed query would work, but pfsense forwarding to it would not..
I take it your domain your hiding is public - having rfc1918 address space in public dns is going to be problematic that is for sure, and is not good practice.
-
I can put other DNS servers in the DNS server list however I need all LAN traffic to use the private DNS server that is only available over the OVPN link.
Catch 22:
- pfSense needs access to a public DNS server to establish the OVPN link
- All client devices are to only use the private DNS server
-
@johnpoz said in Redirecting LAN DNS:
@McMurphy you show your port forward where are you firewall rules on the interface?
So you want this 100.96.1.1 to resolve all your external dns then? Just forward to it. And block all your other dns..
Then pfSense is unable to establish the OVPN link and until established 100.96.1.1 is unavailale
Also if your forwarding to this 100.96 address, and it sends back rfc1918, that 192.168.1.12 that would be a rebind, and no psfense would hand you that address unless you turned off rebind protection for that domain. Which is why a directed query would work, but pfsense forwarding to it would not..
I have worked out how to disable to rebind and this works however if traffic goes through pfSense to 100.96.1.1 as a Forwarder then I still need a public DNS for the OVPN link to be initially established
I take it your domain your hiding is public - having rfc1918 address space in public dns is going to be problematic that is for sure, and is not good practice.
Not at all. I simply have a LAN behind a pfSense router and a DNS filtering service that is accessible via an OVPN link on pfSense. I want everything to function like normal but just use the 100.96.1.1 dns server to filter the DNS requests.
-
@McMurphy said in Redirecting LAN DNS:
I have worked out how to disable to rebind
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html
-
Yes. I can disable rebind when I use either the Resolver or Forwarder however these do not allow me to force DNS down the private OVPN DNS server.
I have read about policy routing but an not sure how it works.
A solution would be to have either:
a) all DNS queries sent to the private OVPN DNS server 100.96.1.1
b) all DNS queries sent over the OVPN interfaceCan this be achieved with policy routing?
-
@McMurphy yes policy routing is how you send a client down a specific gateway, be that a normal gateway or some vpn connection.
-
I believe I have two possible solutions Not sure which is best and if there are quicks with either I have not thought of:
a) Use policy routing to send all DNS over the VPN
b) Use NAT to redirect all DNS enquiries to 100.96.1.1
My preference is (b) if that'll work as expected as the IP 100.96.1.1 will automatically be routed over the VPN
-
I found this, probably not what you are looking for. But if you are using CloudConnexa as your VPN provider, then I thing you need to change your NAT rule. Try to remove the destination address.
https://openvpn.net/cloud-docs/tutorials/configuration-tutorials/connectors/routers/tutorial--configure-a-pfsense-router-to-connect-to-cloudconnexa.html
