Messages

I observed this on Linux, too. The 802.1x implementation of the Realtek-based Unifi switches is fully broken at this time, BTW: During bootstrap, when the RADIUS server cannot be reached, the training does not work, so initially, all 802.1x-enbaled ports go to their fallback VLAN.

What seems to be the case is that those Unifi switches do not wait for the RAIDUS server to become available before the allow 802.1x training (of course, that means you have to initialize non-802.1x-enabled ports first). Gen Z at work, I suppose...

Hopefully this settles your debate over combining tagged and untagged traffic, LOL.

See you again when this goes horribly wrong and you do not even remember what you did to make that possible. We never said it was not feasible, but depending on what you do, there can be lots of problems. This may be influenced by your NIC hardware on OpnSense, and is especially true for Unifi switches, which have all kinds of problems with VLANs. If you want a taste of it, look here.

The current switch software releases of some switch models have a problem separating untagged and tagged LANs during switch startup. Depending on the startup order of your machines, they can get IPv4 from any of your VLANs (since all of them are presented untagged). With 802.1x enabled, you may see all IPv6 prefixes at once on untagged ports.

But, as Patrick often says: You do you, LOL. The advice given in here is free - and you are also free to take it or leave it.

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.