NAT / reply from unexpected source

[jpgpi250]

I have a NAT rule thet redirects all DNS requests, NOT originating from my internal DNS server to my DNS server.

This works fine, the NAT rule redirects the traffic, the DNS server resolves the query, the firewall ensures the client is convinced the reply is coming from the (unauthorized) DNS server.

e.g. dig @8.8.8.8 example.com is redirected to my internal DNS server, the reply appears to be comming from 8.8.8.8 (client perspective).

Now I want to do the following

client request to 8.8.8.8 (or any other unauthorized DNS server) -> NAT redirects to monitoring machine (192.168.3.5) -> monitoring intercepts the request (tcpdump) but the dns request is also forwarded (using dnsmasq) to my internal dns server.

if the client is on a differen subnet than the monitor, it works perfectly, again the originating client is convinced the reply is comming from 8.8.8.8

if however, the client is on the same subnet as the monitor, the reply is no longer processed by the firewall, but is going directly from the monitor machine (dnsmasq is running there) to the client. The result (only for clients on the same subnet as the monitor) is reply from unexpected source.

The question: Is there a way to prevent the dnsmasq instance on the monitoring device to directly reply to the client (on the same subnet), e.g. ensure the firewall does what it needs to do to convince the client the reply is from the DNS server it specified in the request.

Thanks for your time and effort.

[viragomann]

@jpgpi250
You can masquerade the redirections to the monitor with the pfSense interface IP. However, this let the monitor think, that the request is coming from pfSense instead of the origin client.

[jpgpi250]

@viragomann

great....

and how do I do that?

[viragomann]

@jpgpi250
It's to be set in Firewall > NAT > Outbound.

If your Outbound NAT is working in automatic mode switch to the hybrid mode first and save it.

Then add a new rule like this:
interface: this one which is facing to the monitoring / client
protocol: TCP/UDP
source: the clients subnet
dest: the monitoring IP
dest. port: 53
translation: interface address