Messages

[can]

If you know the least thing about Proxmox, you should know that while Docker can be used in an LXC, this is not the preferred way.

What do you mean by "give the solution to Production"? The way you put it sounds like you are the solution architect and tell production personnel to implement it? What is your role?

If you do not know by now, I cannot help you, sorry.

In AGH or Unbound, you have to redirect bad sites to the IP of your blocking webserver.

I gave a link to a project that can handle the blocking webserver (including certificates) part. It needs docker, but if you do not have that or know how to use docker-compose or do it another way, you are stuck.

OpnSense has no means to do it and it is complex by nature. Note that OpnSense is not your average consumer router that will handle these things automagically for you (actually, what you request cannot be done on OpnSense alone).

[If]

I repeat: This approach does not work for HTTPS sites, which nowadays is the default for most sites.

Just think it through:

1. You request any URL, like https://www.badsite.com/url1.
2. No matter what you are using: Unbound, AGH or Pi-Hole see that "www.badsite.com" is on their blocklist.
3. You configure your DNS blocker to NOT deliver a "NOT FOUND" error, but a different IP than the real one for www.badsite.com.
4. The webserver behind that IP accepts the request on port 443. If it can present a certificate for www.badsite at all (for the purpose of which it has to be able to dynamically generate those), it will not be trusted by your browser per se (unless you import the generating CA first).
5. Therefore, your browser will bark and NOT show you the blocking notice, but instead a warning that something fishy is going on (which it is).

Result: You cannot have a blocking notice page (as requested per thread title) without dynamic certificates that your browser trusts.

You will not see the blocking page first, because the certificate is not trusted, so instead, your browser will warn you like this:

You cannot view this attachment.

You cannot prevent that from happening other than with certificate generation & CA import, because a single exemption will not cover all potential blocks.

And there you have it: Your WAN rule has source and destination reversed.

Which has the same problem when you try to redirect to a HTTPS site.

Denying a request for a DNS name and redirecting to another site is not the same thing and even if you return a specific IP, the site behind it cannot easily fake being the original one called for.

Adguard Home is not designed for that purpose - normally, it is supposed to just return a DNS error for "advertisements" that drops requests for advertisement URLs, such that ad content image parts will be left out from your normal pages.

Of course you can use blocklists that also block certain sites and you can specify the IP that AGH returns. You can then install a webserver on that IP that answers with a block notice for any URL. Yet, if the original URL was HTTPS, you would get an error because your block notice cannot produce a valid certificate for the original page called for. Thus, you need to create a certificate on-the-fly, the CA for that must be imported on your clients.

Here is a project that does that, but as I said, this is not how AGH is intended to be used, so it is a lot of manual work. Also, I assume that every advertisement on each page would be replaced by a small picture of the block site.

And your insight on creating blocking rules as floating rules makes sense if floating rules always come first before non-floating rules.

When the new rules scheme was first discussed, this was my main gripe about it, because with the old rules, you could create floating rules purely for precedence reasons. Now, with the new rules, the role of a rule switches with the number of interfaces it applies to (and it can never be floating with just one interface like "WAN only").

We'll see how this plays out when everything is migrated.

Ca depend... with a reverse proxy, it would probably help.

P.S.: Some people like to exclude blocking aliases by using their negation in the allowed source of the NAT rules. My previous preferred way was blocking in the old "floating" rules, but maybe you have to do it differently now.

[think]

I think that may be because of the transition from the old to the new rules, which is not yet finished. With the old rules, this was more apparent, as I tried to explain. However, I do not know for sure and at this point, I do not bother to pursue this, because there is still work underway: For example, the firewall rules are "new", but the NAT rules are still "old" - and frankly, I do not know the exact implications, which is why I suggested to look at what is actually being made of it in /tmp/rules.debug.

You need Unbound or any DNS resolver, so AGH should run on an alternative port. I do not use it, but here is a guide:

https://samuelsson.dev/install-adguard-home-on-an-opnsense-router/

Maybe you should use something different than 5353, because that collides with mDNS.

Yes, because many network drivers implicitely buffer packets, especially small ACK packets. When there is already ongoing traffic, those packets can be piggybacked onto existing data packets.

In most OSes and many drivers, you can tune settings as to what and how this buffering is done. The immediate push of packets incurs a higher interrupt load.

You can look if there are any tuneables for your specific adapter in FreeBSD.

It is not the NAT rule, but the "pass" setting you specified with it. When you select "manual", you can tailor and prioritize a specific rule to your liking, which is what I wrote in #4 already.

The instructions to do this are literally on the linked page.