Reply from unexpected source when using DNS redirection

Hi !

Leaving Pfsense for Opnsense because of a lack of hardware support, i’m forced like many to switch from the integrated ads blocker to Pihole.

When doing so, i’ve setup the same kind of redirection that i usually do to avoid rogue device to override the DHCP provided one.

To do so, i’ve setup a rule in the NAT -> Port Forward section like so :

Interface: LAN + Back
Protocol: TCP/UDP
Source: inverted single host : 192.168.20.84 (IP of the Pihole)
Destination: inverted single host : 192.168.20.84 (IP of the Pihole)
Destination port: 53
Redirect target IP and port: 192.168.20.84:53

This does work well for device in the lan network (192.168.1.0/24) but it break from device in the same network as the Pihole (192.168.20.0/24):

;; reply from unexpected source: 192.168.20.84#53, expected 192.168.20.254#53

I’m guessing this is an issue of “asymmetric routing” ? Have anyone encounter this before even on single subnet network ?

Thank’s

1 Like

To my knowledge blocky is available as a package so no need to use pihole?

Not on my package list at least.
And I’m in need of something rock solid as this will live in my parent house down the line. I can’t afford self packaged or beta stuff for this project.

Included software — OPNsense documentation suggests that it should be available via pkg , it’s stable and likely more robust than pihole.

If you are suggesting a cli install, i would need to look up how to ssh into it.
If it’s supposed to be in the packages list on the GUI, it’s not but it look like i’m updating didn’t bring me to the latest stable, only the latest minor.
I’m upgrading to the latest major right now just to see if it’s there.

Edit:
Nop, not in the GUI


can’t find any doc about it outside of this Blocky on OPNSenese · mimugmail/opn-repo · Discussion #35 · GitHub

it’s not reassuring.
I would love to have something in the router, not to rely on en external machine. But Opnsense is an appliance for me, i need to be able to wipe it and restore it from a backup, no extra fiddling.

I may have missed something, but blocky don’t look like it fit that, And my dns are still broken XD

According to the documentation you need to use pkg but oh well…

That documentation you’ve send it very generic, like for any pkg and not blocky specifically.
Given the scope of this project, i’m considering it “unsupported”. But if it’s compilable under bsd unlike pihole, i’m expecting to see something more official soon !

I’ll switch to it then, but for not for now.

It’s a package manager, why would you duplicate documentation when it’s the same for every package?

That’s my point, your talking about a package like you would on a debian or redhat server when i’m looking to work with integrated and supported feature that work with the UI, backup and all.

Appliance VS Server :slight_smile:

Disclaimer I’m not familiar with FreeBSD firewall at all. Also haven’t used pfSense/opnSense.

I’m little surprise that it actually works for the LAN 192.168.1.0/24 after all! It’s a good thing…

I mean one problem that I ran into in my Linux Router was that in a very similar scenario, a single Destination NAT rule was not enough and I had to create a corresponding Source NAT rule as well. I’m still puzzled why I need to do that. Perhaps just a bug in my Linux Router.

Back to your problem. To workaround the issue, you may try to modify your NAT rule by semantically change

“Source: inverted single host : 192.168.20.84 (IP of the Pihole)”

to

“Source: inverted network : 192.168.20.0/24 (network of Back)”

See if that helps.

Ideally, I’m also interested to hear from the the fundamentals why as-is (without change) the issue happened for:

“; reply from unexpected source: 192.168.20.84#53, expected 192.168.20.254#53”

So it look like when I’m creating a Dnat, the corresponding SNat isn’t created :thinking:
This do look Odd as i would imagine that the source of the reply on the LAN side (192.168.1.0/24) even if routed would still not be the expected one…
Yet i don’t have any error.

Doing so would basically exclude all DNS query from the 192.168.20.0/24 network from the PortForwarding rule. It wouldn’t solve the issue.
I am very confused, but i have been recommended to manually setup a SNAT rule for this.
I just need to know how to do it properly