Flummoxed by DNS

[passeri]

After installing the Dec 697 yesterday everything appeared to work until I found I could not pass DNS queries from one interface. I have as outgoing rules
- LAN any to any - this works
- IoT and Servers - pass anything not to local - appears to work for servers, not for IoT, with a further wrinkle.
- Unbound listens on all ports.
- An override in Unbound allows LAN access to the servers.
- DHCP is Kea.
- Crowdsec is off.

I added a prior rule to IoT to allow port 53 to the firewall, trying by a DNAT rule as advised, and as a direct "pass port 53" which also appeared to allow the traffic to pass but without allowing DNS queries.

Testing Servers to see why it worked but IoT did not with otherwise the same rules, I found something really weird.

I have three computers on the Servers net, all connected to the same unmanaged switch. Using SSH into each and trying

Code Select Expand

dig au.archive.ubuntu.com I found the following results:

• Box 1 answered correctly, from 127.0.0.1
• Box 2 answered correctly from root servers
• Box 3 said servfail from 127.0.0.1

These are identical commands on the same subnet through the same rules.

Are the simple rules sound? What sort of configuration might lead to different behaviours or responses? I have "Use system servers" unchecked. The previous router did not use Kea or Unbound but rules are otherwise copied across.

I can try checking what might be configured in the three boxes. Other than that one is MacOS and the other two Ubuntu Linux they should be the same. My query here is firstly to make sure that there is no immediate flaw in the firewall rules model or related configuration that someone is aware might produce this oddity.

[passeri]

While I am not yet marking this as solved, I think that as Shakespeare wrote, the fault dear Brutus is not in the Opnsense but in our devices. I fixed the configuration on Box 3 - it had been misconfigured to refer to itself and not accept what it was told as a DHCP client. The others are working as configured (one is directed through its own BIND). Given that, I can tackle the IoT question again with more confidence.

I do have one supplementary query while I work on that. Given that Unbound listens on all interfaces, how does this interact with DNS queries sent to the internet or to Opnsense? Does it automatically capture everything or are manual rules necessary for redirection?

Every new thing I learn or read about DNS seems to be shadowed by an equal part of new confusion.

[EricPerl]

Unbound only listens on This_Firewall:53
Queries targeting public servers just go through as usual.
The GUI is on 80+443, and you can still browse...

If you want all DNS queries to go through Unbound, you need to port forward.
That takes care of regular DNS.
Unclear if you care about DoT and DoH. I remember seeing a post from Patrick about that.

[passeri]

Thanks for the clarifications @EricPerl, that fits with one of the sensible patterns I considered so no further confusion there :-).

GUI access is available only to LAN and Wireguard now that it is "in production".

I recall reading that post by Patrick, and DoH/DoT are not things I need to use.

[passeri]

I have verified that everything works normally if I plug a computer directly into the router's IoT port, but not plugged into ports nor via WiFi of the two bridged APs below it.

Therefore the problem should lie with them, ... although they worked under the configuration of the older Opnsense router.....

[EricPerl]

You're pretty much only saying that a computer "does not work" when plugged into APs (but works fine connected to OPN directly).
That's a little thin on details...

IOT is a LAN on a physical interface, right? IOW, not a VLAN.
Are you APs configured to get their IP via DHCP? Static IP (did the range change compared to old setup)?
What are the symptoms on the computer when connected to the APs? Getting IP? Pinging GW? Resolving DNS?...

[passeri]

Sorry, I should not have included that throwaway comment. It was clear enough (earlier part of that sentence) by then that the problem had nothing to do with Opnsense but with configuration of the APs, two Mikrotiks. I compared their configurations with each other using a tool I wrote for analysing Mikrotik configs and found an error in one which, possibly because they are bridged, was affecting DNS. All works now. Thank you for your assistance, and my apologies for not being clearer in the last post, albeit I had not actually solved it at that point.