Messages

Nein, das ist nicht notwendig. Ich würde mal schauen, welchen Weg die DNS-Update-Pakete nehmen (also TCPdump auf der OpnSense). Vielleicht ist noch etwas falsch konfiguriert.

Die einzige Möglichkeit wäre, dass der DNS-Server, dem Du die Updates schickst, zufällig in Deinem internen Unbound-DNS auf die interne IP umgelenkt wird. Deswegen muss man dafür einen eigenen DNS-Namen nehmen, der ungleich dem Webserver-DNS-Namen ist, z.B. ns.domain.de vs. www.domain.de. Und dann trägt man die lokale IP nur für www.domain.de ein, nicht für ns.domain.de.

Yep. But I cannot choose a "Qfeeds" blocklist and I also do not see anything special in the generated Unbound config files, so this seems to have no effect.

"!" bedeutet Negation, also die Checkbox "Destination / Invert" zu setzen. Und dann trägt man die Host-IP in das die Destination als "Single Host or IP" ein. Damit ist alles, was NICHT HOST-IP ist, von der Regel betroffen, nicht mehr "any". Die Einschränkung auf Deine lokalen Clients braucht es gar nicht, weil "any" genausogut funktioniert - wer soll denn sonst fragen?

Schau Dir einfach mal die Bilder im ersten Post des verlinkten Threads an, da sieht man, dass das "Destination / Invert" in der Regelliste zu einem vorangestellten "!" führt, z.B. in "! LAN Address".


Und nein, nochmal, den DNS-Server musst Du nicht ändern. Für die DNS-Requests kann er ganz normal die OpnSense nutzen. Die DNS Updates werden normalerweise sowieso an den authoritativen DNS-Server für die Domain abgesetzt - das ist meist einer im Internet.

Dummerweise sorgt die Redirect-Regel aber dafür, dass JEDER DNS-Request umgebogen wird, neben den DNS-Queries auch die DNS-Updates, die weiterhin nach draußen gehen sollen. Das liegt einfach daran, dass man nur auf den UDP Port 53 matcht, und der ist bei beiden Varianten gleich. Man müsste ins Protokoll hineinschauen, um zu sehen, dass es Update und keine Queries sind, aber das geht nicht so einfach.

Wenn Du die Regel komplett deaktivierst und Deine Clients sich "wohl verhalten", würden sie ja per DHCP auch die OpnSense als DNS-Server genannt bekommen und diese ohnehin nutzen. Die ganze Umleiterei macht man doch nur "on top", um das bei böswilligen oder fehlkonfigurierten Clients zu erzwingen.

Was ist meine ist, dass man das normalerweise so macht, dass man einen Port Forward für Traffic mit Zielport UDP 53 auf 127.0.0.1:53 macht. Dadurch würde jeder DNS-Request von internen Quellen auf die OpnSense umgebogen. Die einzige Änderung ist, dass man in der Regel die Quelle mit !HOST-IP einträgt. Damit ist HOST-IP als einziger von diesem "Umbiegen" ausgenommen.

Ist alles hier beschrieben, inklusive dieses Problems, ziemlich am Ende des Threads.

Es geht doch nur um eine Ausnahme für den Redirect für den Rechner, der das Zertifikat beantragt. Der Redirect soll doch nur dazu dienen, dass kein externer DNS-Server genutzt werden kann, sondern alle Requests auf Zielport 53 auf die OpnSense umgebogen werden (somit auch die DNS Updates).

Durch die Einschränkung erlaubst Du doch nur einem einzigen Host, diese Beschränkung zu umgehen. Das heißt nicht, dass er nicht als DNS-Resolver weiterhin die OpnSense nehmen DARF - nur eben nicht MUSS. Den externen DNS nutzt er doch nur für den DNS-Update. Klar, er KÖNNTE dann auch andere DNS-Resolver nutzen, aber da es sich mutmaßlich um einen Server handelt, wird das doch eher nicht passieren, oder?

Was man mit einer solchen Regel typischerweise erzwingen will, ist, dass IoT-Geräte oder Smartphones den eigenen DNS nutzen müssen.

Wie gesagt, wenn Du den DNS-Redirect wegnimmst, kannst Du ja den DNS update direkt absetzen. Das geht an jedem lokalen DNS-Sever vorbei und bedarf nur einer Regeleinschränkung im Port-Forwarding.

This is supposed to work with Unbound according to the docs, but even after I checked "Register domain feeds", I cannot see anything w/r to Qfeeds in the Unbound blocklists, although both sets (IPs and domains) seem to be licensed.

Oh, I never used those, didn't not know they exist. Are they in a useable format for Unbound?

Machst Du DNS-01 Verifikation? Falls ja, die DNS Updates werden weder durch Unbound noch durch DNSmasq durchgeleitet - beide Server können nur DNS-Queries verarbeiten. Ich habe das gemerkt, als ich versucht habe, mit einem Server "hinter" OpnSense einen DNS-01 update per RFC2136 durchzuführen, während ich alle DNS-Requests über den lokalen Unbound geforwardet hatte. Ich musste für den betroffenen Host eine Ausnahme eintragen.

Probably. The Qfeeds list contain IPs, not domains, so you have to use the alias in a firewall rule, not in a DNS blocklist.

Good question, but I think you could create that rule as the first interface rule as well. Creating a floating rule as suggested only makes extra sure it gets processed first.

It is true that you can inspect the rules. What I miss is the quick overview where you can see the list of rules with all preceeding rules before them like so:

You cannot view this attachment.

[not]

Although I second the opinion that the migration tool will spark much more interest (and problems) with the existing user base on release of 26.1, I have to object OPNenthu's potential rationale here:

Based on what Patrick and I (and obviously, OPNenthu) believed until Friday last week, a floating rule was the only thing that preceeds a port-forwarding "PASS" rule. Thus, our workflow was based on that false assumption. For example, we used port-forwarding rules with "PASS" for simplicity, but has floating rules to black any access from blocklists like Firehol, Blocklist.de or QFEEDs.

Last week, we found - to our surprise - that the docs were correct in specifying that this is not the case. Floating rules are in fact less prioritized than implicit NAT "PASS" rules. You have to create an associated rule, which then goes to the interface rules and thus is always preceeded by floating block rules.

On a side note, such rules will get disassociated during update to 26.1, as discussed here.

And BTW: This is why both Patrick and I asked basically the same questions there. Consider them obsolete.

The only thing about order that I find irritating is that, after migration, the only spot were you can really see what order all al the rules (i.a. automatic, floating, interfaces, groups, automation, "old") are being used in, is the old rules - and those will presumably be removed at some point.

Eine Hürde für jedes zusätzliche (V)LAN ist, dass dort zu Beginn keine "Allow any -> any" existiert, die standardmäßig für das LAN angelegt wird.
Eventuell reagiert deswegen die OpnSense auf den zusätzlichen Interfaces nicht auf den Ping.

Seltsam, dass Du Port nicht als Trunk konfigurieren kannst.

If reducing the MTU size on your Windows client does not fix the problem, them maybe the MTU size is not the problem after all?

Did you try the ping to your OpnSense instance itself, too?

For modern Windows versions, I think they automagically set the MTU size - IDK how they do that exactly, however. I do not have the problem, as both my WAN and LAN MTUs are 1500 bytes.