Messages

[You could also look into "grep -n 'max-mss' /tmp/rules.debug" and see if there is any rule that limits your TCP MSS to 1452.]

Did you reboot? As mentioned, the order of interface initialisation matters and the results upon initial configuration may be different.

I am with the exact same ISP and do not see your results with http://pmtud.enslaves.us/. My setup is shown above, and I get the same effective MTUs as you with the pings but then:

Path MTU Discovery Test
Results
Direction   Tested Maximum Size Segment   Client Sent MSS   Notes
Server to Client IPv4   1460 (MTU 1500)   1460 (MTU 1500)   OK
Client to Server IPv4   unlimited   (n/a)   OK
Server to Client IPv6   1440 (MTU 1500)   1440 (MTU 1500)   OK
Client to Server IPv6   unlimited   (n/a)   OK

Code Select Expand

got server to client probe for mss 536 (max seg 1460)
got server to client probe for mss 1460 (max seg 1460)
got server to client probe for mss 1460 (max seg 1460)
finished s2c4 probing, maximum mss 1460 peer mss 1460 initial peer mss 1460
got client to server probe for mss 520
got client to server probe for mss 1461
got client to server probe for mss 9000
finished c2s4 probing, maximum mss 9000
got server to client probe for mss 536 (max seg 1440)
got server to client probe for mss 1440 (max seg 1440)
got server to client probe for mss 1440 (max seg 1440)
finished s2c6 probing, maximum mss 1440 peer mss 1440 initial peer mss 1440
got client to server probe for mss 520
got client to server probe for mss 1441
got client to server probe for mss 9000
finished c2s6 probing, maximum mss 9000


You could also look into "grep -n 'max-mss' /tmp/rules.debug" and see if there is any rule that limits your TCP MSS to 1452.

Contrary to the instructions one difference might be that I set MSS 1500 on pppoe0 explicitely - although it should not be the culprit, you may want to try it.

Yep, that fixes it.

I see the problem as well, Franco:

Code Select Expand

root@OPNsense:~ #  cat /usr/local/opnsense/changelog/index.json | jq -e > /dev/null && echo good
jq: parse error: Invalid numeric literal at line 120, column 4

The part that is buggy is this:

{"series":"26.7","version":"26.7.9","date":"November 11, 2026"}
,
{"series":"26.7","version":"26.7.7","date":"October 13, 2026"}
,
{"series":"26.7","version":"26.7.1","date":"July 21, 2026"}
,
{"series":"26.7","version":"26.7.6","date":"October 08, 2026"}
,
{"series":"26.7","version":"26.7.8","date":"October 30, 2026"}
,
Use of uninitialized value $date in concatenation (.) or string at /Users/franco/Documents/opnsense/changelog/Scripts/webify.pl line 128.
{"series":"26.7","version":"26.7.","date":""}
,
{"series":"26.7","version":"26.7.r1","date":"July 07, 2026"}
,
{"series":"26.7","version":"26.7.3","date":"August 27, 2026"}
,
{"series":"26.7","version":"26.7.4","date":"September 15, 2026"}
,
{"series":"26.7","version":"26.7.5","date":"September 30, 2026"}
,
{"series":"26.7","version":"26.7.2","date":"August 12, 2026"}
,

Ich verstehe unter "Klonen" die entsprechende Funktion der Virtualisierungs-Software, beispielsweise PVE.

Die klont typischerweise die gesamte Maschine, inklusive der virtuellen Platten, bei Beibehaltung der Plattengrößen. Und dabei spielt das Dateisystem darauf keine Rolle. Was allerdings aus Sicherheitsgründen meist gemacht wird - damit die neue VM keine Konflikte hervorruft - ist, die MACs der NICs zu randomisieren.

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.