Messages

If a previous boot keeps the machine from crashing, I would still update the boot loader just for testing. AFAIU, the old one created memory corruptions.

Could that also have to do something with the old, buggy bootloader that triggered the os-microcode bug in the first place?

I updated all bootloaders beforehand and saw no problems on any system I upgraded.

Or you should take a look at the release notes?

Especially where it reads:

o The CPU microcode early loading has been known to be flaky on some setups.  A fix is in the FreeBSD 15.1 boot loader code, but can only be reached by reinstall or manually updating the boot code of your system after the upgrade succeeded.  If you want to be on the safe side during the upgrade itself please remove the plugin before proceeding.

And then there is this.

Merke: Bei Firewall-Regeln gibt es kein Sicherheitsnetz! Die müssen schon stimmen, d.h. man sollte wissen, was man tut.

Jede Allow-Regel zu viel kann Traffic passieren lassen, den man nicht wollte und jede Block-Regel zu viel kann Traffic blockieren, den man dringend benötigt hätte (deswegen ist meine Konsole immer "offen" - mit physischem Zugriff aufs Gerät ist alles andere eh nur ein Deckmantel).

1. An sich ist es Sache Deiner Clients, wie sie nach nicht-vollqualifizierten Namen fragen. Sie können eine oder mehrere "Search Domains" an den übergebenen Namen anhängen. Das kann man im Client konfigurieren oder per DHCP übergeben. Ob Du Deinen Namensraum in Subdomains (z.B. pro VLAN / Zone) unterteilst, ist Geschmackssache.

2. Bei dynamischen Präfixen ist das schwierig. Es gibt vier Möglichkeiten:

a. Du kannst ULAs zusätzlich zu den GUAs nur für den internen Traffic nutzen - allerdings werden ULAs bei der Auflösung niedriger priorisiert als IPv4, also ist das nicht so ideal.

b. Du kannst eine Art NAT66 nutzen, bei der Du intern einen "eigentlich unbenutzten" IPv6-Präfix verwendest, und den auf die echten GUAs 1:1 zu mappen. Das ist aber ein dirty trick.

c. Du kannst mittels DynDNS alle diejenigen Clients im DNS eintragen, die Du per DNS erreichbar machen willst (das sind vielleicht gar nicht alle). Geht, ist aber aufwendig. BTW: Man kann die Eintragungen die OpnSense übernehmen lassen, weil der DynDNS-Client (dynamische) Interface-Präfixe mit einem bekannten EUI-64 Suffix verbinden kann.

d. Du verwendest intern nur IPv4, um Geräte addressierbar zu machen - das funktioniert dank NAT, weil die internen RFC1918-IPs ja konstant bleiben. Nur für bestimmte Clients, die von außen erreichbar gemacht werden sollen, verwendest Du Methode c oder besser, Du verwendest einen Reverse Proxy, der dann auch IPv4/IPv6 wandelt und verschlüsselt.

Das letzte ist i.W. der Ansatz, der hier erläutert wird: https://forum.opnsense.org/index.php?topic=45822.0 - BTW: Nicht alle Clients können überhaupt IPv6, weshalb ich im gesamten internen Netz Dual-Stack mache.

3. Ebenfalls Geschmackssache, aber wenn nur Deine OpnSense den Upstream kennt, kannst Du das zentral umswitchen bei Bedarf - wenn Du den alternativen DNS per DHCP mitteilst, musst Du auf den Renew warten (abgesehen davon gibt es ja auch statisch konfigurierte Clients).

4. Ich würde es eher umgekehrt machen und dem Unbound den Pi-Hole als Upstream nennen. Wen der als Upstream nutzt (z.B. Cloudflare o.ä.), oder ob er selbst auflöst (weiß nicht, ob Pi-Hole das kann), ist seine Sache. Natürlich darfst Du die DNS-Pakete nicht in einer Endlosschleife herumschicken.

5. Normalerweise gar nicht, denn DNS-Server können IPv4 und IPv6 auflösen. Wie der Server selbst erreicht wird, ist egal. Und per SLAAC wird nur mittels einer Extension (RDNSS), die nicht alle Clients verstehen, überhaupt der DNS-Server verteilt. Eigentlich war das nur per DHCPv6 vorgesehen.

6. Windows zaubert mit DNS sein eigenes Ding. Ich trage in der smb.conf einfach die Namen des Hosts ein, dann wird das per Broadcast bekannt gemacht. Ich habe noch nie einen SMB-Share über VLAN-Grenzen genutzt, im Zweifel müsste man das per IP (\\192.168.x.y) machen.

7. VPN of your choice, z.B. Wireguard Road Warrior Setup, siehe Dokumentation. Damit ist Dein VPN-Client ja "wie zuhause".

While you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.

I doubt that they would do that depending on specific ranges.

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.