Messages

Alternatively (better?) use a reverse proxy on OPnsense. That definitely terminates the TCP connection at OPnsense, which as a BSD system is not affected by this Linux bug.

...creating new security threats in the process.

[heutigen Tag]

1. Es gibt bereits eine Community Edition und eine Business Edition.

2. Ungeachtet dessen haben wir 2026. Es gibt inzwischen KI-gestützte Werkzeuge zum Auffinden von Sicherheitslücken, und die Bedrohungslage entwickelt sich ständig weiter.

Ausgerechnet das von Dir kritisierte Update 26.7.8 vom heutigen Tag enthält zahlreiche Sicherheitskorrekturen. Siehe:
https://docs.opnsense.org/releases/CE_26.7.html

Die Verfügbarkeit von Updates ist kein Mangel, sondern ein Feature. Ob Du diese Updates einspielst oder mit den bekannten Schwachstellen und der entsprechenden Angriffsfläche lebst, ist Deine Entscheidung.

Die Business Edition verfolgt bewusst einen konservativeren Aktualisierungspfad mit weniger häufigen funktionalen Änderungen, um den Anforderungen produktiver Unternehmensumgebungen Rechnung zu tragen. Wenn Dir das wichtig ist, gibt es genau dafür ein kostenpflichtiges Angebot.

3. Genauso wenig ist die Verfügbarkeit unterschiedlicher Werkzeuge für DHCP und DNS ein Mangel. Sie erfüllen teilweise unterschiedliche Anforderungen. Dnsmasq eignet sich für kleinere Installationen, Kea bietet unter anderem Vorteile bei Skalierbarkeit und Hochverfügbarkeit. Unbound wiederum ist in erster Linie ein DNS-Resolver.

Entscheide Dich für die Werkzeuge, die zu Deinen Anforderungen passen.

Und es war übrigens nicht Decisos Entscheidung, ISC DHCP einzustellen. ISC hat die Entwicklung und Wartung bereits 2022 beendet.

Things change. Deal with it.

4. Auch die IPsec-Terminologie ist nicht einfach eine Laune der OPNsense-Entwickler. IKE SAs und CHILD SAs sind etablierte technische Begriffe. Die neue Oberfläche orientiert sich stärker an strongSwan und dessen tatsächlichem Konfigurationsmodell. Und die von Dir kritisierten Pools dienen beispielsweise der IP-Adressvergabe an mobile VPN-Clients.

Natürlich kann man darüber diskutieren, ob die Oberfläche intuitiver gestaltet oder besser dokumentiert werden könnte. Aber aus der Tatsache, dass Dir eine Terminologie nicht vertraut ist, folgt nicht, dass sie unlogisch wäre.

5. OPNsense ist ein professionelles Netzwerkwerkzeug. Vielleicht liegt hier ein grundsätzliches Missverständnis vor. Lies einmal:
https://forum.opnsense.org/index.php?topic=42985.0

Insbesondere den Satz gleich am Anfang:

Be warned: OPNsense provides a GUI for professional networking features; it does not turn them into consumer-grade settings that can safely be changed by trial and error. Or it can — but then there is plenty to try, and plenty to break.

Netzwerke sind komplex. Eine grafische Oberfläche kann diese Komplexität zugänglicher machen, aber sie kann sie nicht beseitigen.

O.K., MikroTik treibt das mit seinen nahezu unbegrenzten Konfigurationsmöglichkeiten vielleicht etwas weit. Aber OPNsense? Echt jetzt?

Höchstens die MACs der NICs - je nachdem, ob die VMs gleichzeitig im selben Netz sind. Umgekehrt können bei neuen MACs IPv6- oder MAC-basierte Regeln versagen.

The microcode update was not the root cause of the problems many people had. The old bootloader was.

There are threads which show how to update it.

[entirely]

I fully understand what you are trying to achieve. The problem is that your questions are still based on assumptions that don't quite reflect how DNS and network security work today - 8 years after the initial post has been made.

First, the choice of DHCP server (ISC, Dnsmasq, Kea) is largely independent of the question of enforcing "old-style" DNS resolution through OPNsense. So, in this sense, the guide is still applicable.

But there is a much more fundamental issue:

Redirecting traditional DNS queries on TCP/UDP port 53 is relatively straightforward. Preventing DNS leaks in general is an entirely different matter.

Clients may use DNS over TLS, DNS over HTTPS, DNS over QUIC, application-specific resolvers, VPN tunnels, or other mechanisms to bypass your local DNS infrastructure. Some of these can be blocked relatively easily; others cannot be reliably distinguished from legitimate traffic by ordinary firewall rules. Some of the limitations have been discussed in the course of this thread.

Restricting your network to IPv4 doesn't eliminate these problems, either.

So before trying to apply a supposedly working set of specific firewall rules, you need to define what you actually want to enforce:

- Prevent accidental DNS leaks from normally configured clients?
- Prevent applications from using alternative DNS resolvers?
- Prevent deliberately non-compliant clients from bypassing your DNS policy?

These are very different objectives, requiring different approaches, with different limitations.

There is no universal set of firewall rules that guarantees all DNS resolution will pass through your local resolver while otherwise allowing unrestricted Internet access.

Until those limitations are understood and the actual objective is clearly defined, a step-by-step configuration guide would only create a false sense of security on your part.

Which do you mean? The first post, which now is ~8 years old? Probably not.

There are several posts in here that discussed additions on DoT, DoH and gave directions on what can and what cannot be done. This is largely independend of the DNS service in charge. The guide is essentially about how to use firewall rules to redirect queries to that service, be it Unbound, DNSmasq or any other of your choice. Even to that extent, additions have been made, e.g. the initial post does not cover IPv6.

Ich habe einen Verdacht: Du hast offenbar sowohl auf dem physischen LAN-Interface (10.10.2.2) als auch auf dem VLAN-02-Interface (10.10.2.1/24) IP-Adressen aus demselben Subnetz konfiguriert.

Falls das LAN-Interface ebenfalls die Netzmaske /24 verwendet, wäre das ein Konfigurationsfehler. Der Kernel könnte Pakete für 10.10.2.0/24 über das falsche Interface routen, also ungetaggt statt über VLAN 02. Dass `pfctl -d` nichts verändert, würde dazu passen.

Prüfe bitte auf der OPNsense-Konsole:

Code Select Expand

ifconfig -a
netstat -rn -f inet
route -n get 10.10.2.9

Interessant wäre insbesondere, welches Interface bei `route -n get` angezeigt wird.

Mit "tcpdump -eni <VLAN-Interface> 'arp or icmp'" könntest Du zusätzlich prüfen, ob Ping-Anfragen ankommen und Antworten zurückgehen.

Wenn das physische LAN-Interface nur als VLAN-Träger dient, sollte es selbst keine IP-Adresse haben. Die 10.10.2.1/24 gehört ausschließlich auf das VLAN-02-Interface.

Dass das bis 26.7.5 funktioniert hat, könnte an einer geänderten Interface-Initialisierung oder Routing-Reihenfolge liegen.

From your description, the main obstacle is the complexity of your setup and the lack of a controlled baseline for troubleshooting. You describe several different symptoms without having established where each failure occurs. Systematic fault isolation comes before BSD-specific expertise.

A crucial distinction here is between configuration and runtime state. An unchanged configuration does not imply unchanged behaviour. DNS answers, DHCP leases, ARP caches and firewall connection states change during normal operation. Security products can update signatures, reputation data and blocklists automatically. The same configured policy can therefore produce different results as its inputs and state change. Looking for manual configuration changes will not explain those differences, and the absence of configuration-change logs is entirely unsurprising.

You have also combined several access-control mechanisms whose interactions need to be understood. Some combinations have documented restrictions: Zenarmor and Suricata in IPS mode, when using netmap, require separate interfaces because they cannot both own the same netmap interface. That is one concrete example of why individually useful security products cannot simply be combined without checking interoperability.

Running the Proxmox firewall alongside the OPNsense firewall introduces another independent filtering layer. Traffic dropped before reaching the VM cannot appear in the guest firewall's logs. Each layer needs to be investigated at the point where it acts.

Wireless networking - being unreliable at best - adds further variables. Access points may perform ARP broadcast-to-unicast conversion or multicast-to-unicast conversion, introducing additional processing and learned state. These features can require disabling for particular applications; TP-Link's own Omada guidance for Sonos is an example. A connected Wi-Fi client therefore does not establish that every relevant type of traffic is being delivered correctly.

These examples illustrate the diagnostic problem; they do not establish suspected causes of your particular failures.

The important point is that these variables create combinations. The diagnostic search space grows multiplicatively as configuration choices, runtime states and interactions are combined. Understanding each component individually is insufficient if you cannot also account for their combined behaviour. Thus, you need a minimal, known-working baseline, one reproducible symptom at a time, and tests that locate where communication breaks down. Reinstalling everything and restoring the same configuration also restores any configuration problems it contains, so Proxmox does not help you there, either.

Realistically, you are unlikely to find volunteers willing to reconstruct and untangle this entire environment free of charge. A forum can help with specific, sufficiently isolated problems. You need to do the groundwork yourself: reduce the complexity of your setup and present one clearly isolated, reproducible failure at a time.

[you]

maybe you should refrain from exposing an administrative interface to the open

Why do you keep moving the goalposts? OPNsense is vulnerable in its default configuration.

Which goalposts, exactly? Patrick had already explained that the GUI is not accessible from WAN or newly added VLANs by default. I am referring to a security boundary that already exists.

For a direct attack against the GUI, an attacker first needs network access to it:

a. You have exposed the management interface to an untrusted network. That would be a configuration change you made, not the default configuration.
b. The attacker is on a LAN from which management access is permitted. If your threat model includes attacks from those LAN clients, restricting their access to the administrative interface is your responsibility.

The presence of a PHP vulnerability does not make the packet filter disappear. Assessing whether an attacker can actually reach the vulnerable service is fundamental to assessing exposure and urgency.

The bug needs fixing, I give you that. That does not make the existing security boundary irrelevant, and me pointing that out is not "moving the goalposts."

If anyone is moving the goalposts here, it is you: you are turning a discussion about actual exposure into a blanket demand for an emergency patch. The default configuration blocks direct WAN access. If your urgency instead stems from exposing the GUI to the Internet or to LAN clients you consider potential attackers, then that exposure results from your own failure to restrict administrative access appropriately.

[today]

The project must ship a PHP update today, and must accelerate work on not running any components of the web UI as root.

...or maybe you should refrain from exposing an administrative interface to the open? Besides, there is the checkbox "Strict Security" - which does not help much (read on!).

Guys, we now live in 2026, not 2010. If you think that this vulnerability is the only one that AI has found, think again: It is only one that has been made public.

FWIW: I am using ~one week in a month just to keep ahead of these things (see this for an example on why running non-root does not really help at all) and to save me some work, I just ordered a Spark DGX to help me do it, because I do not trust cloud AIs to keep my secrets...

Ja, wenn Dein ISP es erlaubt (in Deutschland muss er) oder wenn Du die Identifikation des Original-Moduls klonst.

You did neither tell your configuration nor the topology, so this is only guesswork:

1. Mixing up tagged and untagged (V)LANs on FreeBSD/OpnSense does not work too well. You should have either one or the other.
2. Some hardware does mix up VLANs as well, especially cheap switches. For example, if you cascade switches, an edge switch might short-circuit both VLANs, which can lead to all kinds of problems.

bei den MTUs hab ich nachgeschaut, da steht in der schnittstellenbeschreibung der Anbieter, 1492 drin
so ist es auch auf im Interface auf der OpnSense, als "calculated"

Wie oft heißt es hier, ja - aber. 1492 ist Default, manche ISPs lassen Mini-Jumbo-Frames zu.

930 MBit/s ist angesichts des PPPoE-Overheads so ziemlich das Maximum für Gigabit - deshalb sind ja ONTs mit 2.5 Gigabit manchmal hilfreich, insbsondere, wenn der ISP überprovisioniert, wie meiner.

Einbrüche können diverse Ursachen haben, manchmal sind es schlechte ONTs (oder hier: Medienkonverter), manchmal auch einfach Überprovisionierung seitens des ISP. GPON kann 2.5 GBps Downstream, de facto ist das aber meistens ein "Shared Medium" - deshalb können andere Nutzer auf dem selben OLT-Port Deinen Speed verringern.

Da stellt sich doch zuerst die Frage, ob Du die gebuchten Werte erreichst oder nicht?

Ansonsten ist das ein weites Feld, bei dem viel schiefgehen kann, u.a.:

- schlechte/zu kleine Buffer in manchen ONTs
- Geschwindigkeit bei PPPoE liegt normalerweise unterhalb 1 GBit, falls Link Router <-> ONT auf Gigabit limitiert ist (bei SFP ist eine Umgehung schwierig, weil SGMII oft nicht unterstützt wird, bei Ethernet kann man 2.5Gbos nur verwenden, wenn NIC und ONT das unterstützen).
- Mini-Jumbo-Frames (falls unterstützt) können die MTU wieder auf 1500 Bytes heben.

No, because if you read the documentation closely, you'll see that the design deliberately abstracts from the specific network topology. There isn't necessarily a dedicated WAN port on the Proxmox host to monitor. In my case, for example, the ONT is connected to a switch port.

More importantly, a link-up event does not tell you whether the physical firewall has been shut down. Accidentally connecting something to that port could activate the emergency instance while the physical firewall is still running, resulting in conflicting IP and MAC addresses. Besides, monitoring ports on PVE is far more intrusive than what I would want security-wise.

The intention is to keep the cold spare in maintenance mode during normal operation, so it can be updated regularly and independently of the physical firewall. Switching to emergency mode is a deliberate manual operation after ensuring that the physical firewall is no longer active.

This is a **cold spare**, not an automatic failover solution. If you want automatic failover, use a proper HA setup.