Messages

I use PPPoE and enabled microcode updates and RSS. Otherwise, see this, point 10.

Oh, yes. Of course you have to both enable RSS as per documentation and also check with multiple streams...

[three]

In fact, there can even be three different IPs in play. With CG-NAT or another NAT router in front, you have:

a. your WAN IP as visible in the interfaces overview (with CG-NAT, it would probably start with 100, with a NAT router, it could be from the RFC1918 range).
b. the IP of your upstream gateway as shown on the dashboard.
c. the IP your requests apparently come from when asking myip.dk or similar sites. This can be either your WAN IP, or with NAT, the WAN IP of whatever router does it (with CG-NAT, from you ISP's ASN).

You need to understand which is which to interpret the results right.

[/24]

Did you set 192.168.20.21/24 and also set the gateway correctly (e.g. 192.168.20.1) for the LXC? Miss that and it won't work - basic stuff, you know.

I am using X520 connected via DACs and I just tested with 26.7.1_1. I can get >5 GBit/s with "iperf3 -P4".

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.