Messages

Thanks for the fast response.

Updates work on the five units.

You cannot view this attachment.


Three of them have no problem, two of them don't seem to be happy with the file format.

In five different OPNsense, all of them on 25.7.9:

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

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.