Messages

FWIW: Ich habe eine (von drei) Installation bei DG, bei der nach einem Neustart die IPv6 erst nach ca. 10 Minuten vergeben wird.

Keine Ahnung, wieso.

Take a look at the Tutorial section - there is a HowTo for IPv6.

The business license that comes with Deciso boxes is valid for one year only, so it probably has expired.

I assume you want to set up a bridge with LAN and LAN2. Follow the Offizials docs, them it will work.

Miscconfiguration: why do you use two logical interfaces for pppoe?

If that does not work, I can only imagine two reasons:

1. You have your local unbound be responsible for home.arpa as a whole, such that sub-zone are not delegated any more.

2. Somehow the firewall rules or something blocks your OpnSense from accessing 192.168.178.3 on port 53. Being able to resolve from a client on your LAN is not the same as doing the same from OpnSense itself, especially when a VPN in involved en route. Try an nslookup from your OpnSense instance and then track down where that goes.

Note that Google Driver will not work anymore for new users: https://forum.opnsense.org/index.php?topic=48393

Probably because it expects to handle TLS termination and distribution of sites to different backend by itself, anyway.
However, even if it does that, a reverse proxy should aim for maximum transparency, also with the client info that is passed on.

I like HAproxy better as well. It has some distinguishing features that set it apart and with @TheHellSites tutorial, it works just great for me.

[anything]

The question is too broad in general. What exactly should AI aim at in OpnSense?

- Finding software vulnerabilities? Yes, that is possible and is seems quite conceivable that Anthropics' Mythos model may find some bugs in the building blocks of OpnSense. But actually, that is not "using AI" in the product in the strict sense.

- Helping block hacking attempts? Because of the fact that AI does not "understand" anything, this may create errors of both first and second degree (i.e.: block both less and more than desired), like almost any old-fashioned IPS would do - which is why I do not trust those. Happy hunting for things that do not work if you try that...

- Helping users configure their firewalls? Well, at least you can argue that an AI will not lose it like some of us experts sometimes do... but seriously, I doubt that the results would be convincing. Been there, done that - and I consider myself somewhat knowledgable in the field. I even fear to imagine a beginner configuring OpnSense in tandem with an AI. On the other hand, you never know, maybe that is better than the beginner alone...

- So finally, an AI might also be useful by bringing to mind what high level of expertise is needed to configure a firewall by hacking away at users' setups on demand - in the hopes of finding at least the most obvious misconfigurations.

[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.