Messages

Mit der geringen Info, die Du geliefert hast, sind nur prinzipielle Antworten möglich, nichts konkretes:

1. Natürlich kannst Du das getan haben, das meiste spielt sich allerdings im Firewall-Bereich ab.
2. Jein. Es sind nicht nur WAN-Regeln, sondern z.B. auch NAT.
3. Ja, absolut und ja. Da IPv6 kein NAT benötigt, reicht ein falsches "Allow Any" in den WAN- (oder Floating-) Regeln aus.
4. Ja, sollten sie, sonst brauchst Du ja keine VLANs. Und genau da spielt ggf. auch IPv6 rein, denn jetzt müssen die Pakete eben nicht mehr über das WAN reinkommen.
5. Richtig. Das gilt für die übliche "Allow Any"-Regeln bei IPv4.
6. Ob man das mit einer Regel und invertiertem Ziel oder mit zwei Regeln (eine mit Block RFC1918 und eine mit Allow Any) macht, ist Geschmackssache. Über VLAN-Abschottung auf Ebene IPv6 habe ich noch nicht nachgedacht, denn der Bereich ist zu groß, um ihn zu scannen. Das bedeutet: Das schlimmste, was Dir passieren könnte, ist, dass ein Client in einem VLAN einen anderen in einem anderen VLAN erreichen kann - nur: wie soll er ihn finden?

P.S.: Du kannst in der Ziel-Adresse auch "INTERFACE net" angeben. Und wenn Du alle lokalen Interfaces zu einer Firewall-Gruppe zusammenfasst, gibt es auch "LOCAL_VLANS net". Dann kannst Du als Ziel !LOCAL_VLANS net nutzen für die Allow-Regel. Tatsächlich habe ich das sogar genau so gemacht und zwar sowohl für Version "any", also für IPv4 und IPv6 - ich nutze !RFC1918 gar nicht.

Again: See post #37 or use the forum search.

By courtesy of Patrick, who more than once explained this (not his exact words):

To answer the "why" (not to bind a service to a specific interface):

When you do that, the interface must be configured before the service is started. Often times, that is beyond your control, so it won't always work - and if it fails, you wonder why, just like in this thread.
If instead you leave that out, the service will bind to "any", which includes interfaces that pop up later.

You should restrict access via firewall rules instead.

This now made it to here, point 32.

Since the firewall is the culprit, you can check your firewall rules during a ping test from the client. You have the client's console available, because it is on Proxmox. Then, check the firewall live log (Firewall → Log Files → Live View) for a block and identify the blocking rule. If there are none, enable the "default block" rule logging in the settings.

If need be, you can verify if the traffic even arrives at the VLAN interface via tcpdump.

Also, check the alias if it really contains .21 - matter-of-fact, I recently had an incident where I created an alias, but then found under Firewall → Diagnostics → Aliases, that it was empty. Only changing the alias, applying and changing it back healed that.

Without doubt, you will find either a block rule or a rule that specifically allowed only your specific range or a rule where you reversed source and destination, i.e. a block rule that is too broad or an allow rule that is too narrow to allow the traffic.

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.