Messages

Your clients must somehow get to your OpnSense, normally this is done via some kind of dynamic DNS update - unless you have static IPs.

The only ways your remote clients know at which IP they must direct their WG VPN packets to are:

1. Static IPs.
2. A DNS entry that can be resolved and points at whatever IP your OpnSense has at the time, especially with dynamic IPs. It is this entry that must be present in the client configuration - and AFAIK, it is not automatically included in the peer configuration that OpnSense generates.

So, you must create and upkeep a DNS name under which your OpnSense can be reached - at least if your WAN IP address changes at times. Also, when the connection drops, the connection must be re-initiated by the client, potentially with the same DNS entry now pointing to another IP adress.

If the connection is not created at all, logs will not help you. You can try to do a tcpdump on the WAN interface in order to see if packets on the Wireguard target port even reach your OpnSense. If that is the case, you can try to enable logging for dropped packets and find out why they are blocked.

Obviously your clients cannot connect from outside. That may be because of different reasons, it can even fail before your own WAN firewall rule kicks in, like:

- bad DNS resolution, so that your client cannot find your Wireguard endpoint.
- double NAT setup (router-behind-router), like when your OpnSense is behind an ISP router instead of a bridge modem or ONT.
- your ISP providing CG-NAT only, which essentially is double NAT as well.

Show-the-rules (i.e.: all of them). Order matters. Interfaces matter. Direction matters. New rules or old matter - especially, when old rules have not been deleted.

From what it sounds, you have a preceeding rule to allow that kind of traffic before your blocking rule can hit.

You can also get /tmp/rules.debug and throw it at an AI of your choice together with the packet you think it should block for an explanation. For those types of work, an AI is actually quite good.

What else would be the intent of HTTPS introspection? As I said, Adblocking (and even kid safety) can be done with DNS and / or IP blocking (that is, iff you also control DNS tightly).

The easiest point to intercept HTTPS traffic is on the endpoint device itself, not by interfering with traffic on any intermediary (to prevent that is essentially a design goal of traffic encryption in the first place).

In my experience, if you want enterprise-level security, you conceptually will have to use a layered approach, because punctual measures will be circumvented sooner or later. If you do not need to protect your users from themselves, you do not need most of that, anyway.

That of course includes 802.1x, DNS redirection (plus blocking of DoT and DoH, which is also hard), and control of HTTPS traffic (preferably on the endpoint), not to forget blocking VPN traffic of any kind.

To do all of that is a major effort which most people - including me - will not take, but it is certainly a nice playing field.

Try to do it with your IoT devices and you will see what I mean. Essentially, they will have no internet access at all, because you cannot inject your own CA into most of them. If you then exempt them from HTTPS inspection, you are all set when somebody uses an IP in the exempt range.

That means: a homelab with IoT devices and stuff means exemptions are neccessary and then anybody can use those IPs. Even if you use VLANs, if you do not also have 802.1x (aka "enterprise features"), anybody can circumvent it. I never said that it can only be justified in an enterprise context - it is only achievable in an enterprise context (with a lot of work), not in your average home network with lacking features and given requirements. And as you say: "At work...".

That is what I meant by "you can't". You can - but it will not keep your kids safe, not even speaking of them using LTE on their mobile phones when they find blocking in your WLAN or using a free VPN. Ad blocks and other stuff can easily be done via DNS blocks, so what can you actually achieve?

I think that this is not worth the effort, but you do you.

Sorry, but I still do not get what the actual problem is:

a. You can tell the dyndns updater to use any (static) suffix you like.
b. You cannot know which temp addresses a client will use - so you cannot update dyndns "in lieu" for a client for a temp address - but that is not neccessary, because there will always be a static IPv6 under which the client can also be reached, so you can use that.
c. Same goes for OpnSense itself, iff that even used temporary adresses.

When you forget about your scripts and formulate the exact problem: what type of dyndns adresses are those that you want to make accessible that are problematic? OpnSense itself or clients? Temp addresses or "static suffixes"?

The next step is to understand how to do and implement https inspection.

Easy: You don't. See this, point 12.

Deine Screendumps zeigen ein /56 für das LAN, das wäre falsch, es muss /64 sein. Du musst ein beliebiges /64 Präfix aus Deinem /56er Bereich wählen.

Typischerweise ist die WAN-IP übrigens /128. Geht IPv6 von der OpnSense selbst?

Bad luck on the firewall box (although you probably got your money back from Amazon), congratulations on your electricity rates.

But: depending on where you live, half of 360 Watts running 24/7 sets you back 180/1000*24*365 kWh * 0,30€/kWh = 473€ per year (that is about average in Germany). So, in just something over one year, a (working) specimen of an N1x0 box is amortized, because that only sips 15 Watts.

Reality is a little better, hopefully, because even these things do not even use half of 180 Watts permanently, but you catch the drift...

Anybody can screw up firmware, all good if they fix it later on (even if it takes years after initial product release).

However, the first link seems to be a hardware/design problem, so that one cannot be healed at all, IMHO. The only thing that comes to their rescue is that nobody noticed the hard part before. That is, if not being able to split up a 10 Gbps connection to eight 1 Gbps ports is not bad enough in the first place (at least that is not a complete functional show-stopper).

[just works.]

So this is my last stop before I order a ubiquiti that just works.

Like this? Or this? Want more?

Es gab mal einen Thread, wo darüber berichtet wurde, dass es trotzdem für bestimmte Abfragen noch Traffic über Port 53 gibt - ich weiß nicht mehr, wofür das genau benötigt würde. Mir ging es hier nur darum, festzuhalten, dass es weiterhin Traffic über Port 53 gibt aus mindestens zwei Ursachen:

1. Client -> OpnSense
2. OpnSense -> Internet (trotz DoT)

Es gibt hier zwei Sorten Anfragen:

1. Welche von Deinen Clients zu OpnSense - die laufen auch bei Nutzung von DoT weiter über Port 53.
2. Welche von OpnSense zu den Upstream DNS-Servern. Die hast Du anscheinend auf DoT per Port 853 umgestellt.

Wenn diese #2-Anfragen nicht mehr per normalem DNS auf Port 53 laufen, funktionieren sie auf Port 853 nur verschlüsselt, weil das Zertifikat des Zielservers geprüft wird. Stimmt dort der Name nicht, geht's nicht. Auf welchem Port wirklich DNS-Anfragen rausgehen, kannst Du z.B. per TCPDUMP auf dem WAN-Interface prüfen.

Am Rande bemerkt, gehen nicht alle DNS-Anfrage per 853 raus - beispielsweise die erste nach der IP des DoT-Servers nicht - aus Gründen.

I nearly fell for it.... April Fools.

@drosophila: But that does not change the way how most of this is done within OpnSense, by creating the interfaces aorund the specific implementation of the various services, like that currently, even the actual MAC->IPv4 tables are edited and saved for each service individually. @pfry put it right: There currently is no abstraction layer.

Also, that abstraction layer could catch even more than the uniform usage of different services, but also the jump from the MAC->IP to the IP->DNS layer, including aliases. It could also cover the problems around the dynamic to static transition of devices.

What I mean by that is that now, with Kea, when you first put a device on the network, it will get a dynamic IPv4. Yes, you can make that static - but that does not work at all, because the lease is not deleted and conflicts with the static reservation, thus creating a big problem in its wake.

Imagine a "client" entry that can be created manually or automatically upon first contact, where you just fill in the blanks, like change the DNS name, add DHCP options or DNS aliases and so forth, thereby creating a static reservation, while deleting the Kea lease underneath.

But doing that would be an initial design choice, trading limiting capabilities for ease of use. I doubt that it could or even should be tried in OpnSense.