Messages

Check document.

Editing the rule, at the bottom, you'll find "Advanced features".
Click to "Show" them and change "reply-to" to "disable".

Regards!

[TL;DR]

TL;DR

Traffic to 127.0.0.1 can be redirected.
Redirect (DNS/NTP/...) to 127.0.0.1 as usual.
Do not forget to put "PASS" rules for the services you want to access (DNS, NTP...)


Explained and solved:

I already have an alias for RFC1918 (plus some other reserved networks, like 224. 240, etc). I use it for egress traffic from internal networks to internet (one rule per interface).

Trying different approaches to this question, I put your configuration in a NAT rule and it didn't work. Then, I changed the DNS server in a client, pointing to a public external DNS. Then, the rule is catching the queries and redirecting to Unbound (!). So yes, 127.0.0.1 can receive redirected traffic.

Then, I created a floating rule to allow DNS to "This firewall" and now, everything works as intended.

The wrong point was that, in the process of re-writing some rules, I changed the default "allow any" rule for outbound traffic to the more restrictive "!RFC1918", but I forgot to create rules for the services requiring them. Redirecting to the "Internal_IP_Addresses" alias creates an associated fw rule that permits DNS to those addresses, so the clients with the fw as DNS servers were allowed by that rule.

It was a(nother) Layer-8 problem, after all.

From the firewall perspective, 127.0.0.1 is a valid address, but it seems that pf doesn't translate traffic from an interface address to 127.0.0.1, at least in the OPNSense implementation.

Solution:

1. Create an alias containing the internal IP addresses of the firewall:

   Enabled: checked.
   Name: Internal_IP_Addresses
   Type: Hosts
   Content: 192.168.1.1
            192.168.10.1
            etc.

2. Use the alias in the NAT > Port Forward rule:

   Interface: Check the internal interfaces you want to apply the rule to.
   TCP/IP Version: IPv4
   Protocol: TCP/UDP
   Destination /Invert: checked
   Destination: This Firewall
   Destination port range: DNS (53)
   Redirect target IP: Internal_IP_Addresses (as an Alias)
   Redirect target port: DNS (53)


I don't know if this is by design, comes from pf, or OPNSense feature or issue. If someone could clarify this point, it would be great to know.

Regards.

There is a "General Settings" tab next to "Accounts". By default, the "native" backend is selected, so no ddclient config.

Creating a "Custom" account profile can be a workaround but it doesn't explain why the no-ip profile fails in your case.

Sadly, lack of logs for this service makes tracking issues hard.

Mine is working flawless at this time.

The only difference is that I only have my hostname in the list.

I do have the same line in logs but it's some minutes before the update. No logs about correct updates.

It was half (or less...) a joke, but a PR as a plugin could probably be taken into account, if it satisfies the plugin requirements and structure and here too.

I think it should have a button to play the selected item, as rebooting the machine is rarely done. It would just call the "beep" script, I suppose.

I can't code, but would have already built it for my own use, at least.

I doubt that writing a set of default rules for a new interface seems a good idea. This is specially true in a VPN interface, which is used in so many different ways as users are.

This idea deserves not only a plugin, but also a pull request!!!

;-)

Go to Reporting > Unbound DNS > Details (tab)

There is a column which title is "TTL".

Thas is the time left for each particular entry to expire. Once it's expired, Unbound must ask for it again. Some sites gives long TTLs while others are very short, that's up to the domain name's owner.

So yes, it's fine, all the records will eventually expire and will have to be asked again.

Regards.

[zone]

There is a note in that link to the docs. I think that is what you are missing: zone, then hosts.

Note:
.internal is the IANA and ICANN approved TLD (Top Level Domain) for internal use. If you instead own a TLD, e.g., example.com, you could create a zone thats not used on the internet, e.g., lan.internal.example.com.

Hi.

The very last message before yours was about exactly the same topic.

For more info, search "wireguard stale".

Regards.

[Same as b.]

Not only a privacy question, but control at hands, too.

On the privacy side, I can't see how DoT and DoH could help:

a. You use your ISP's DNS > they capture DNS + associated traffic (http, https, smtp...)
b. You use an external DNS > DNS server capture DNS data and your ISP captures associated traffic.
c. You use an external DoT or DoH DNS > Same as b.

In all the above alternatives, you lose recursion on your DNS, which becomes a forwarder and your ISP will always know your traffic, ISP doesn't care about DNS data.

d. You use your own DNS server > You are in control about filtering and no DNS data for free to other entities. ISP, of course, sees your traffic.

DNS data has no value for the ISP, as they have your traffic anyway. At least, don't give that info to one (or more) corps, orgs, or whatever.

That's my point of view about encripted DNS systems in small or even medium networks. That could be different for a multi-site bigger net. Other thinkings really appreciated, probably there are some benefits I am missing.

Regards.

Thank you all for your answers.

So this is the behavior I was looking for. I already have DNSBL running on Unbound. Will check the DNSSEC option and put a NAT redirect rule, to assure all clients have DNS access, even with other config out of my control.

I know that other DNS servers offer additional services, but I prefer to ask only root servers and keep control of what happen before/after that.

I see the point putting additional sever/s in the network, but, for now, I don't see the need for it. If Unbound can't resolve chances are the OPNsense machine has crashed (so no internet, too) or root DNSs have gone down (so no internet, too). Swapping the OPNsense for another machine or router would be a viable patch in that case.

Again, many thanks for your attention.

Hi all!

I recently moved 4 otherSense installs to OPNsense and added one more. Then I discovered this awsome forum and found a lot of interesting info and details about a lot of things about OPNsense and even networking.

I read this and then this one.

@Patrick M. Hausen says,

Unbound is a perfectly capable recursive DNS server that does not need any upstream.

so I removed the upstream servers in System > Settings > General and made sure "Allow DNS server list to be overridden by DHCP/PPP on WAN" is unchecked. My clients are either manual IP or reserved DHCP with only the OPNsense as DNS, have rules to block outbound traffic to port 53 and allow 53 on "This firewall" only. It just works as I supposed, according to Patrick's explanations.

Is this the way of having Unbound to do all the job described in the second link?