Messages

Yes, and ironically, NetworkChuck gave the root API key to the AI agent... :-(

Well, before that he bought a chinese box with RealTek NICs, so what could we expect?

[unsolvable trust problem]

1. I hope you are aware of one unsolvable trust problem once the models or # of tokens get too big to handle with a local LLM: Even if you limit the model to read-only access and implement user safeguards a.s.o.: the user must still trust big tech by using their AIs.

Keep in mind, that there are lots of sensitive data in the firewall configurations, ranging from VPN keys to potentially, CA private keys.
To see where I am going with this, just read this in a similarly sensitive context - the author of that tool does either not comprehend of what he is doing or he really is a sock-puppet (also, at the time he first presented his project, he had no verifiable history in the tech community). He even claims that his tool is "The Proxmox MCP you can hand the keys" - yet all of his attempts are futile in that he is neither an expert in Proxmox nor AI models and he cannot even program himself (all is done by Claude).

I sure hope you do not fall for the same misconceptions.

2. That being said, your links do not work at this time. I always get a 404, so I cannot verify or try out anything you have done - I would never do that on a production machine, BTW and urge others to apply the same caution. There have been attempts lately to lure unaware OpnSense users into installing tools on their boxes, up to creating a facade company website with a catchy name. So, I also hope the moderators are closely watching this.

By now, I would say: Let's not AI OpnSense if the MCP server is implemented in a way that makes non-local LLMs neccessary or needs anything installed on the box itself. I know that is a high hurdle, but hey!

I think you misinterpret that: The color green stands for the UP state, the square is the button for stopping the service. This is the same as with most audio equipment, like tape decks or CD players.

You are right, the public key I gave was for Germany only. I corrected the first post accordingly.

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.