Transparently Intercept and Redirect DNS Traffic to an Internal DNS

johnpoz

Because pfsense knows the name, and it does a PTR for it..

How pihole assigns name to an IP is via a PTR query for the IP..

gniting

@johnpoz I tried this setup and it works, as in I do get the right host name at the pihole end, but I get the following error as well:

❯ dig @8.8.8.8 dns-redirect-test.com
;; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53

; <<>> DiG 9.10.6 <<>> @8.8.8.8 dns-redirect-test.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

192.168.8.2 is the IP of the pihole.
LAN1 (on which all devices sit) is 192.168.7.x
LAN2 (on which pihole sits) is 192.168.8.x

Probably something to do with properly setting up an outbound NAT rule but I've tried diff configs, none seem to resolve the issue.

Any pointers are welcome.

Marv21

@ibbetsion
The NAT Rule is only valid for the .7. net?

gniting

@Marv21 the redirect NAT rule is set up for the .7. net.
In the image below, SYNAPSE_LAN = .7. net.

Marv21

@ibbetsion
dns_ok is 192.168.8.2 then - right?

Marv21

@ibbetsion

Where are you running this Dig command from?
A client from the 7 or the 8 Net?

gniting

@Marv21 Sorry for omitting that, dns_ok is an alias that I use for those hosts that are allowed to make queries to external DNS servers. Any local host not in this alias/group should be re-routed to the local DNS server at 192.168.8.2

gniting

@Marv21 the dig command is running from a host on the 7 Net.

johnpoz

@ibbetsion said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53

No shit what do you think was going to happen... This is why you put your NS your going to redirect to on a different vlan.. Or you have to forward it to loopback.. So pfsense does the query, and then sends the answer..

gniting

@johnpoz the NS is on a different subnet...

Marv21

@ibbetsion

could you try this just 4 fun?
Thats mine. So everything will be redirectet from LAN to the SYNAPSELAN (any - directed to to that net or not)

gniting

@Marv21 said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

@ibbetsion

could you try this just 4 fun?
Thats mine. So everything will be redirectet from LAN to the SYNAPSELAN (any - directed to to that net or not)

That caused all DNS resolution to stop working. I think the issue is somewhere else. I am also now finding out that I cannot ping (or ssh) from the 8 Net to anywhere on the 7 Net or anywhere else. But I can go from 7->8 Net. Need to solve that first :)

Marv21

@ibbetsion
Have you a allow Rule on the 8 net?
YOu need to allow traffic to 7.

gniting

@Marv21 said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

@ibbetsion
Have you a allow Rule on the 8 net?
YOu need to allow traffic to 7.

Yes, there is an allow rule on 8.

johnpoz

@ibbetsion said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

the NS is on a different subnet...

You can not run multiple layer 3 on the same layer 2 and call it a different network..

For what your seeing to happen, the NS you redirected to had direct access to answer the client..

. I am also now finding out that I cannot ping (or ssh) from the 8 Net to anywhere on the 7 Net or anywhere else.

Seems you have bigger issues in your network than just trying to redirect dns..

gniting

@johnpoz I was able to resolve the other issues. Everything is on track except for the unexpected source issue.

A bit more on the network setup.

ISP modem connected to pfsense on WAN port
pfsense's LAN1 port connected to an unmanaged switch which in turn has all other local devices on it
pfsense's OPT1 port connected directly to host running DNS/pihole

LAN1=192.168.7.x network
OPT1=192.168.8.x network

johnpoz

Then what your seeing makes zero sense...

So I can for sure duplicate your problem when the NS is on the same network..

root@ntp:/home/pi# dig @8.8.8.8 www.google.com
;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53

But if I put it on a different subnet works fine, or if forward to loopback, or if setup nat reflect auto outbound nat rules so it

You can see from this sniff, pfsense saw traffic to 8.8.8.8, sent it on from its own interface 3.253 to 3.10, got answer and then sent answer back to 3.32 looking like it came from 8.8.8.8

But yes if client thinks it sending to A, and gets back answer from B - its going to complain.

gniting

@johnpoz makes zero sense to me too, hence the continued head-scratching

I do have the option enabled to Enable automatic outbound NAT for Reflection. On your network, you have the NAT redirect rule and that's it?

Marv21

@ibbetsion
Both are /24 ?

gniting

Yes