Messages

No worries, thanks for confirming. I don't mind setting wireguard to secure this dns traffic (and perhaps other traffic as well) and it seems to be a pretty common solution. I imagine crypto offered by wireguard would be better than ssl anyway.

> I guess you could run getdns/stubby and Unbound/dnsmasq as its upstream resolver with the help of firewall rules.
I don't think opnsense let's you do that? There doesn't seem to be any configuration to insert your own certificate. I know unbound can do it, but I don't know if any changes that are now made via webgui won't get overwritten by opnsense?

> I just don't get why you'd want to encrypt the client side but that's no criticism. We all do things our way ;)
thank you, too often questions like that get derailed by someone telling you that your initial assumptions are wrong, but as you mentioned that's besides the point. I want to protect dns requests of other nodes if any one of them ever got compromised.

or should I just setup wireguard tunnel instead? It'd be probably better than SSL anyway. a bit confusing to use wireguard for something that has already three separate RFC proposals (and dnscrypt), but perhaps it will come in handy for some other purpose later anyway (and running a stub resolver didn't seem that appealing anyway).

I got confused by DNS over TLS feature in Unbound DNS resolver in Opnsense - I thought it will allow clients to connect to opnsense Unbound on port 853 and benefit from encryption and authentication. Turns out that DNS over TLS is only offered from Ubound to another recursive DNS server.

Could anyone please advise me how/if this can be setup in opnsense? I want clients to connect to opnsense Unbound on port 853 using DNS over TLS (using unbound as a recursive resolver).

A user asked in 2022 what's correct way to add static arp entries to opnsense. They linked to an older discussion where users were adjusting static_arp_pairs configuration directly in /etc/rc, but as he pointed out this would be overwritten by opnsense future updates.

I wanted to clarify that since around January 2024 opnsense provides Neighbors menu that let's you insert such static permanent arp entries (applies after reboot).

I wanted to mention this as these posts seemed to score higher in internet search engines than the above documentation page, so I was hoping this post will get clumped with others and help out some future users.

Yeah, I should have drawn a network topology before asking this question, otherwise it's quite to hard to wrap your head around (especially when you don't have access to the network.) I was pinging from a device on "main" subnet (192.168.1.182) to a device in a subnet behind opnsense (10.176.54.16)

thanks to [chatgpt](https://chatgpt.com/share/679fc7de-9a00-800c-9dea-d665f0e70549) I was finally able to recognize that issue wasn't related to firewall rules at all, but to lack of route to subnet behind opnsense in the internet facing router. I initially erroneously thought that adding route will be only required on the host from which connection was initiated and forgot about the internet facing router

I didn't appreciate complexity of routing, makes me question if performance advantage of disabling NAT was worth it, perhaps I will read more about it to avoid getting tripped in the future again

troubleshooting opnsense proves to be very difficult when you can't just disable half of the automatically inserted firewall rules (big part of it though is just complexity of networking in general)

UPDATE: it turned out that modification to firewall was needed after all, otherwise opnsense itself isn't able to reach internet in current configuration for some reason
floating rule did the trick, but not sure if it's too permissive, need to test other options, not sure why it's needed in the first place yet though

I'm suspecting that opnsense autogenerated rules cause my routing to fail. It should be possible for the user to opt-out of these rules.

UPDATE: issue turned out to be unrelated to firewall rules, nonetheless if I could have easily turn them off I would have quickly recognized that they are irrelevant to the issue instead of wasting a day fiddling with firewall rules (especially when you are new to opnonsense)

also here is output from pfctl -sr currently: https://0x0.st/8K8C.txt
I'm able to ping 9.9.9.9 from opnsense  if pfctl -d disables firewall, although still unable to  ping it from devices behind igb1 (assuming firewall needs to explicitly allow forwarding of traffic between interfaces?)

Hi Patrick, thanks for looking into this, yes, I don't think I mentioned port forwarding, like you said they just should communicate between these networks. I tried adding firewall allow rules to every interface in many combinations (all quick) and they do nothing ;/

I'm totally lost, tried everything and this still doesn't work ;/ may as well just enable NAT even though it doesn't make sense to NAT two private networks

thanks, I would very much appreciate help. I've only had experience with iptables on linux, but firewall seems much different on openbsd. My intent: two interfaces with two separate private networks routed by opnsense. No NAT, just routing. WAN interface isn't internet facing, it's part of another private LAN.

Interfaces Overview: https://0x0.st/8KX9.png
WAN rules: https://0x0.st/8KX1.png
LAN rules: https://0x0.st/8KXj.png
pfctl -sr: https://0x0.st/8K8C.txt
NAT disabled: https://0x0.st/8KXe.png
Logs Live View: https://0x0.st/8KXy.png https://0x0.st/8KXv.png
however logs only show blocked IN packets, even though I expected OUT packets blocked (when trying to run curl/ping from LAN subnet)

Now device from WAN subnet can reach device on LAN subnet, but not the other way around (device on LAN subnet can't reach devices on WAN subnet, it can't reach internet gateway neither).

Any hint would be greatly appreciated.

I'm perplexed by the exact same problem as was described here, namely why putting NAT rules to "Disable outbound NAT rule generation (outbound NAT is disabled)" disables outbound routing between interfaces? I expected it to disable NAT, but let traffic be forwarded freely between interfaces (after allowing it in firewall rules).