Messages

Es stimmt, die 750er hat bei mir auch nur ca. 7 Gbit/s maximal gebracht und dazu musste man schon tunen - ich habe die aber auch nicht empfohlen. Der wesentliche Vorteil ist der niedrige Verbrauch und die passive Kühlung. Spätestens mit IDS ist bei 10 Gbps.

Ah, I see. You obviously need that. IDK of a more selective RA filter that just rejects IPs.

What if you set the tunable sysctl net.inet6.ip6.accept_rtadv=0? Apart from the WAN, you do not need RAs on local interfaces. And you are still free to use a DHCPv6 client on WAN and/or RA server on any other interface.

With Unifi, you actually can use VLAN 1, but it is tricky:

You can create a VLAN 1 and name it. And then, you can create a named port profile with no native VLAN and allow all tagged VLANs. If you do that, VLAN 1 will be tagged, too.

Matter-of-fact, I have two "trunk-type" port profiles, one with the usual setup where VLAN 1 is the "native" VLAN as usual, which is used for APs, uplinks and devices, where the native VLAN is 1 and one for OpnSense, where the "fully-tagged" port profile is used. This works perfectly.

You also can do "all tagged" on Unifi APs and switches as well, but the default is that they normally expect their management VLAN to be untagged, so adopting a new one in an otherwise "all tagged" network setup would require a special "adoption port" on the switch and after adoption, you would have to move the AP.

Therefore, the proposed setup better bridges the gap between OpnSense's "do not mix tagged and untagged on the same interface" and Unifi's expectations.

You cannot view this attachment. You cannot view this attachment.

Correct, the source address is NOT your WAN address. And if you want to rule out further errors in the firewall rules, use "pass" before you try something more difficult.

Was ich jetzt schreibe, klingt vielleicht überheblich oder wie ein persönlicher Angriff, ist aber ganz sachlich gemeint:

Ich empfehle eine Fritzbox, wenn Dich die Komplexität der OpnSense überfordert.

Es ist schlicht unmöglich, ein Werkzeug wie OpnSense mit derart vielen Freiheitsgraden auszustatten und gleichzeitig einem "Laien"-Anspruch zu genügen, dass das auch alles ganz einfach und quasi "idiotensicher" gemacht wird. Ich schrieb hier schon mehrfach, dass Leute, die ein Youtube-Video ansehen und sich dann denken: "Ich mache mein Heimnetzwerk jetzt irgendwie sicherer!" zumeist in einem Irrtum behaftet sind. Deswegen sind meine Artikel nicht nur Hilfestellung, sondern - wenn man sie richtig versteht - gleichzeitig auch Warnung, worauf man sich einlässt, z.B.: https://forum.opnsense.org/index.php?topic=42985.0

Einem Gegenargument sei vorweg begegnet: eine vorgeschaltete KI wäre auch keine Lösung für dieses Dilemma, dazu führe ich im Proxmox-Forum (Komplexität ähnlich hoch) gerade eine Diskussion.

Do you operate the two connections from the same location? For multi-WAN setups, you must disable "Reply-To" on WAN connections to avoid assymetric routing.

Also, to avoid your RFC1918 IPs to the main gateway(s), you should set null routes to them: https://forum.opnsense.org/index.php?msg=259031

Stable Privacy wäre für jeden Server das Aus, wenn sich der Präfix ändert.

Jein. Du könntest Dir die neigbor table ansehen, ob irgendeine IPv6 genutzt wird, die nicht der EUI-64 für die MAC entspricht.

Nur: Was macht das vor dem Hintergrund der Fragestellung für einen Sinn? Jeder Client kann verschiedene IPv6 haben, mehrere GUAs, Link-Local-Adressen und ULAs. Für den DynDNS spielt es doch nur eine Rolle, wie man den Client erreichen kann. Selbst, wenn er zusätzlich privacy-IPs nutzt, bleibt doch die aus der MAC (oder DUID) abgeleitete, "quasi-statische" GUA erhalten - und genau die will man ja erreichen, also auch per DynDNS bekannt machen bzw. mit einem Dynamic IPv6 Host Alias per Firewall-Regel freigeben.

Die privacy-IP wird ja nur ausgehend genutzt.

P.S.: Das ist ja gerade der Vorteil, dass Opnsense den DynDNS Update machen kann anstelle des Clients: der würde ja die privacy IPv6 nehmen. Bevor das in OpnSense implementiert wurde, musste der DynDNS Service die EUI-64 ,,maskieren".

Vielleicht mal hier lesen: https://forum.opnsense.org/index.php?topic=45822.0

Genau. Man kann den bekannten EUI-64 Suffix angeben und das Interface, auf dem der Client hängt, für den Präfix.

Leichenschändung - I like! Also seit 2021 haben sich da zwei Dinge geändert:

1. OpnSense kann inzwischen die GUAs von Clients per DynDNS updaten, so dass Variante 2 funktioniert.

2. Falls die bereitgestellten Services HTTP(S) sprechen, bietet sich die Möglichkeit an, einen Reverse Proxy wie Caddy, Nginx oder HAproxy zu nutzen (siehe Tutorial-Sektion des Forums). Dann braucht man nur eine DynDNS-Adresse, nämlich die der OpnSense, die kann dann auch die TLS-Terminierung machen (vorzugsweise mit Wildcard-Zertifikaten), der Rest läuft dann namensbasiert. Man benötigt dazu nur noch CNAMEs auf den DynDNS-Eintrag. Das funktioniert sogar für DS-Lite als Dual-Stack, wenn man auf einem vorgelagerten VPS einen zweiten Reverse Proxy nutzt.

This could be a case of asymmetric routing or maybe, problems because of mixing tagged and untagged VLANs on the same interface.

Since it is Proxmox, you may have also configured both subnets on that...

Bridge mode of course. I do not like double NAT. It is a Leox LXT-010H-D, BTW.

I have verified the gc time for the routes on that system to be 300s:

Code Select Expand

# cat /proc/sys/net/ipv4/route/gc_timeout
300

This would not be a problem in itself, it is just that with this configuration, an ARP request from the ONT will not work.

Thus, reducing the ARP timeout on OpnSense to 300s or below will do the trick.

Was wäre denn Deine Erwartung? Kein reines Failover, sondern Load-Balancing? Der Failover wählt doch das funktionierende Gateway anhand der Priorisierung aus, oder? Selbst wenn Du Load Balancing konfigurierst, bestimmst Du ja nicht selbst, welches Gateway genommen wird.

P.S.: Multi-WAN funktioniert nur für IPv4....

The "Default allow LAN to any rule" is an automatically created rule for your first LAN. Other than that, it is then handled like any other manual rule, i.e. it can have logging enabled or disabled.

The settings in Firewall:Settings:Advanced are for rules "behind the scenes" which are not part of your own rule set and which - apart form some checkboxes - cannot be manipulated from your own ruleset.

I cannot say why this log entry was created, however, there is a small info button on the right of each log line (at least in the live log), if you click on it, you will see the details. Within those details, you will find a link to the "rid" (aka rule id), which gives you the precise rule that led to this log entry.