Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - JeGr

#61
Quote from: meyergru on October 21, 2025, 12:20:10 PMHatte Patrick schon gesagt. Ihr habt Recht, allerdings ist das mit DDNS-Domains oft ein Problem, weil man den DNS nicht vollkommen kontrollieren kann (z.B. nur A- und AAAA-Records eintragen).

Stimmt, wenn Peter und sein Team bei deSec/dedyn nicht genau deshalb ihren Dienst dafür getrimmt hätten ;) Darum wollte ich das nochmal kurz anhängen, sollte es jemand via Suche o.ä. finden, dass das durchaus geht und bei dedyn/deSEC auch kein Thema ist. Die legen da sehr viel Wert drauf, einen sauberen und funktionalen DNS zu haben der DNSSEC bis oben spricht. :)
#62
German - Deutsch / Re: DynamicDNS, Hetzner wechselt API
October 21, 2025, 11:59:03 AM
Quote from: konrad63897 on October 21, 2025, 11:56:34 AMHat da vielleicht jemand schon eine Idee dazu, oder sollte man besser auf die Kollegen vom os-ddclient warten?

Hängt davon ab, was nutzt du denn aktuell um DDNS zu machen?
Ansonsten haben die meisten Plugins ja "Custom" Varianten, wo man einfach die neue API entsprechend reinwerfen kann.

Cheers
#63
Quote from: meyergru on October 03, 2025, 04:01:57 PMMan kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Da das noch so im Raum stand und ich das noch anhängen wollte nach dem Durchlesen des Threads hier:

Doch. Keine Ahnung wo du das hernimmst, dass das nicht erlaubt wäre. Natürlich darf ich ein Wildcard für eine Subdomain erstellen. Haben wir mehrfach im Einsatz. Bspw. für sowas wie "*.dev.domain.tld". Das wäre ja sehr bescheuert, wenn man nur Wildcards auf erster Ebene aber nicht auf höheren erstellen dürfte ;)
Und dedyn hält sich da komplett an den Standard und erlaubt das auch. Das war lediglich ein Knoten in der Konfig, aber können, tut es sowohl Dedyn/deSec als auch ACME. :)

Cheers!
#64
Quote from: srieder.SweetCity on October 21, 2025, 11:41:27 AMUm das Problem (Subnet 172.16.126.2/26 an der OPNsense, mit Verbindung via IPsec, zu 172.19.184.3/24 auf Sophos) zu defineren, und um die Config mit Sophos einfacher zu halten.
Denn wenn ich alles in einen Tunnel mache, dann benötige ich mindestens 3 Einträge mehr; wegen den Subnetzen, die Sophos ansonsten nicht "getrennt" betrachten kann im Routing.
Und wie gesagt, wenn ich nur einen Tunnel mache (mit mehr Einträgen), dann wandert das Problem mit.

Dann sag ichs nochmal: IPsec mit EXAKT IDENTISCHER Phase 1 darf es nicht 2x geben. Du kannst das nicht trennen, weil das kaputt ist. Nur weil sich was aufbaut, heißt nicht, dass das funktioniert. Dass es nicht funktioniert siehst du ja bereits.

Ein Tunnel zwischen 2 Geräten über die exakt gleichen IPs darf nur einmal aufgebaut sein. 2x wäre nur sinnvoll, wenn der 2. bspw. an einer Seite über eine andere Schnittstelle geht (bspw. WAN1<->WAN und WAN2<->WAN auf den Geräten). Aber die gleiche P1 darf es nicht geben, sonst ist das ein Duplikat und je nachdem welcher Hersteller das ist, hüpft der dir im Quadrat und killt die Verbindung.

Die Sophos im Log sagt ein Auth Problem, die OPNsense sagt dir "decrypt" Problem im Log, weil die Pakete in der falschen Phase ankommen (encrypted vom ersten Tunnel, kommen aber nach dem Aufbau von Tunnel 2 im falschen Tunnel an weil die IDs überlagern).

Das macht keinen Sinn, das gehört alles in die gleiche P1 zwischen den gleichen Geräten. Dass die Sophos dann das Problem hat, dass das mit den "3 Einträgen mehr" dann doof gelöst ist -> willkommen bei IPsec und jeder implementiert es anders. Das ist eben leider so. Manche Spieler können Multi-Netze in einer Single Phase 2 abbilden, andere nicht, da muss man jede P2 einzeln definieren und aufbauen. Und AFAIR ist Sophos letzteres und kann das nicht, ergo muss man eben jede Source<->Destination Konstellation in P2 gießen.

Darum auch der Hinweis bei Fragen zu Netzplanung, Design, VLAN etc. immer das Netz so zu planen, dass ichs bspw. bei VPNs als eine große Einheit greifen kann um die Anzahl an P2s (IPsec) oder Routen (OVPN/WG) simpel zu halten.

Cheers :)
#65
Quote from: grefabu on October 06, 2025, 03:57:30 PMEvtl. war eine Einstellung noch nicht auf den HA Backup übertragen,...

Wichtig da gern überlesen/ignoriert/nicht gewusst: OPNsense hat bereits seit einiger Zeit KEINEN automatischen Sync mehr zwischen den beiden Cluster-Nodes. Diesen muss man entweder explizit über einen Scheduler/Cron-Job einrichten oder man muss daran denken, manuell zu synchronisieren. Der alte Mechanismus, dass jede Änderung automatisch gesynct wird (wie nach dem Fork von pfSense) gibt es nicht mehr!

Das ist wichtig, da stolpern leider viele drüber, die sich da nicht up2date gehalten haben, was dann darin endet, dass dort dann ein völlig veralteter Standby Node mitläuft, der überhaupt nicht korrekt "übernehmen" kann, wenn es brennt.

Cheers!
#66
Quote from: djcroman on October 10, 2025, 02:46:16 PMSuper, vielen Dank. Dann weiß ich, wo ich ansetzen muss. Dann mach ich mich mal ans Werk.

Stichwort ist Radius-based VLAN beim WiFi mit 802.1x Enterprise WPA. Dazu kann man auch den Freeradius der *sense ran ziehen und den nutzen. Da bei Enterprise WPA User/PW gebraucht wird statt PSK hängt man das VLAN im Radius einfach an den User - fertig. Gerät bekommt dann beim Einloggen mit der User/PW Kombi das VLAN wie definiert. Man hat dann eben die 2. Abhängigkeit bei WiFi, dass die Firewall mit Radius up&running sein muss, sonst gehen die Geräte nicht, aber wenn die FW nicht läuft hat man meist andere Probleme ;) Heißt aber auch: bei Update/Neustart der FW können Geräte aus dem WLAN fliegen. Daher überlegen, ob man das an der Stelle vertretbar auf der Firewall oder lieber extern haben möchte.

Cheers!
#67
Quote from: meyergru on October 18, 2025, 12:14:55 AM2. 172.16/12 wird u.a. von Docker et.al. für internes Networking genutzt - ich habe nie probiert, was dann passiert, wenn das LAN auch Adressen darauf verwendet.

Eigentlich egal, außer jemand hat Docker oder Container fix in spezifische Netze gemappt. Docker macht eigentlich ein Probing, ob das entsprechende Netz was es sich greifen will (random) frei ist oder nicht.

Ich würde auch eine ordentliche Netzplanung vorschlagen, aber IM 172.16-32.x.y Bereich. Für die meisten Homelab oder halbwegs normalen Firmennetze ist 172.16-32 eigentlich ideal. Ich empfehle da zwar auch 16 und 32 zu vermeiden weils immer in Dokus gern rangezogen wird, aber bspw. 172.24 etc. ist keine schlechte Idee. Mit einem /19er Bereich hat man da genug Platz für allerhand VLANs, kann sich passende VLAN IDs zusammen murmeln und wenn man im Design nicht gerade die massiven Fehler macht, ist das ganze noch topp erweiterbar.

Warum 172.? Weil 192er gern für irgendwelche SoHo Boxen/Router/Modems/blah in use ist und 10.x dann eben meist bei Hostern, ISPs, Cloud, etc. verbummelt wird. Da hat man mit 172 noch eine super Ausgangsposition, auch mal was Privates mit 192 anzubinden oder was Corpo/Cloud-mäßiges im 10er ohne dass man Kollisionen hat.
Wenn man sich dann ordentlich intern umschaut, was man sinnvoll in VLANs packen sollte (merke: kleinere Netze bevorzugt, gerade und auch wegen IPv6 auch wenns im ersten Moment doof klingt), dann hat man sehr fix nen Dutzend VLANs beisammen. Bei mehr als 60% Usage von Netzen würde ich eine um 1 größere Maske nehmen.

Sprich: Beispiel - 172.24.0.0/20 reicht mir doch dicke! -> sind 16 Netze à 24/VLANs. Dann fang ich an zu zählen... oh. Management, Server, VoIP, Drucker, Kameras, IoT Gebimsel, Medienkram, Admin-only Zeugs, Isolierte Sachen, Clients1, Clients2, Gäste, Portal... hoppla sind schon 13-14. Also >60% in use -> größere Maske

Also nochmal Grübeln und komme noch auf Clients3, WLAN1, WLAN2 -> 16 Stk. Und weil voll nehm ich die Maske eins Größer -> also 172.24.0.0/19

Wenn ich dann irgendwas mit meinem Netz machen muss was Routing angeht, bspw. via VPN, etc. hab ich alles sofort mit einer einzigen Netzmaske erschlagen. 172.24.0.0/19.

Ein kleines Beispiel für ein Homelab mit Segmentierung und Planung:
Subnet Calculator für 172.24.0.0/20 (Homelab Beispiel)

Dann noch VLANs drunter, die man schön mit 24 (2. Teil der IP), xx (3. Teil der IP) vereinfachen kann. Also bspw. 2400, 2401, 2402 jeweils zu den Netzen. Ja das klappt nur bis 99 und nicht immer. Aber wenn man schon alles neu macht, kann man das auch "handlich" machen, damit man an Hand der IP auch gleich das VLAN hat und damit einfacher debuggen :)

Cheers!
\jens
#68
Hi,

Quote from: srieder.SweetCity on October 21, 2025, 10:27:48 AM- 2x IPsec zwischen den beiden (1x mit 3 Subnetzen, 1x mit 1 Subnetz)

was genau heißt 2x IPsec zwischen den beiden: 2x ein IPsec Tunnel mit exakt gleichen Daten? Warum? Oder was genau ist damit gemeint?

Zu den Logs: bei der OPNsense ist das etwas wenig Log, da sind keine genaueren Infos drin. Zumindest sieht man da IMHO keinen Fehler. Könnte man das Logging erhöhen, aber ich wäre erst einmal an Info zur ersten Frage interessiert. Es gehen nämlich eigentlich keine 2 Tunnel (P1 mit identischen Daten) zwischen den gleichen Endpunkten. Da können die Geräte schlicht nicht zwischen unterscheiden. Darum ist es eigentlich nicht erlaubt. Verstehe auch den Grund nicht ganz, wahrscheinlich wegen dem einen Subnetz, das sich nicht verbinden will? Das ist dann aber das Problem dieser einen Phase 2 und nicht eines, wofür man einen komplett neuen Tunnel baut?

Cheers,
\jegr
#69
Quote from: sw1980 on September 18, 2025, 06:58:45 PMWeiß jemand, warum das so ist und ob kann man das verhindern kann?

Wenn du bei der Forwarding/NAT Regel das mit einem Source Alias wie GeoIP eingerichtet hast, dann gilt dieses Alias von intern NICHT, da die Quelle dann das interne Netz nicht mit drin hat. Sprich dein Forwarding gilt nur von außen, das kannst du via NAT Reflection nicht von intern aufrufen. Wenn es intern via SplitDNS bspw. aufgerufen wird, dann sollte es je nach Setup funktionieren (kommt auf die Weiterleitung an). Alternativ, wenn das mit NAT Reflection gehen muss, dann muss in deinem Source Alias auch das/die internen Netze, aus denen es funktionieren soll mit inkludiert sein.

Andere Alternative ist statt einfach mit grober Kelle NAT Reflection zu nutzen, das nur selektiv für intern manuell einzurichten, von Verbindungen aus, die funktionieren müssen, damit die auto NAT Reflection nicht einfach wild das auf allen Interfaces durchkonfiguriert.

Cheers!
#70
German - Deutsch / Re: Captive Portal
September 19, 2025, 04:45:42 PM
Hi,

ist das via HTTPS oder mit Weiterleitung auf HTTPS eingebaut? Kannst du im Quelltext der Seite was sehen, ob die Komponenten zum Login überhaupt nachgeladen wird wenn das Formular nicht angezeigt wird? Evtl. gibts da einen Fehler bei der Einbettung des Logins?

#71
25.7, 25.10 Legacy Series / Re: Netbird plugin won't start
September 12, 2025, 04:51:09 PM
Edit:

Did a bit more poking around on a second instance. It seems the problem stemms from

/usr/local/bin/netbird up -m 'https://api.netbird.io:443' -k '22BCF562-xxxx-xxxx-xxxx-1CA4723CC26B'
as that is what configd is stumbling over. I checked on the console that the binary itself can be run. That was fine. Upping with the parameters like in the error threw those errors on the console:

2025-09-12T16:42:41+02:00 INFO ./caller_not_available:0: 2025/09/12 16:42:41 WARNING: [core] [Channel #1 SubChannel #2]grpc: addrConn.createTransport failed to connect to {Addr: "/var/run/netbird.sock", ServerName: "localhost", Attributes: {"<%!p(networktype.keyType=grpc.internal.transport.networktype)>": "unix" }, }. Err: connection error: desc = "transport: Error while dialing: dial unix /var/run/netbird.sock: connect: no such file or directory"
2025-09-12T16:42:42+02:00 INFO ./caller_not_available:0: 2025/09/12 16:42:42 WARNING: [core] [Channel #1 SubChannel #2]grpc: addrConn.createTransport failed to connect to {Addr: "/var/run/netbird.sock", ServerName: "localhost", Attributes: {"<%!p(networktype.keyType=grpc.internal.transport.networktype)>": "unix" }, }. Err: connection error: desc = "transport: Error while dialing: dial unix /var/run/netbird.sock: connect: no such file or directory"
2025-09-12T16:42:44+02:00 INFO ./caller_not_available:0: 2025/09/12 16:42:44 WARNING: [core] [Channel #1 SubChannel #2]grpc: addrConn.createTransport failed to connect to {Addr: "/var/run/netbird.sock", ServerName: "localhost", Attributes: {"<%!p(networktype.keyType=grpc.internal.transport.networktype)>": "unix" }, }. Err: connection error: desc = "transport: Error while dialing: dial unix /var/run/netbird.sock: connect: no such file or directory"
Error: failed to connect to daemon error: context deadline exceeded
Error: failed to connect to daemon error: context deadline exceeded

If the daemon is not running please run:
netbird service install
netbird service start

So I checked the service. It is installed and set up but - of course - not started. Starting it does nothing as it gets stopped immediatly. But the CLI for `netbird service` shows that the global flag -k for key registration can be send with the service keyword, too. Not only with the up command (which should only bring it up when configured). So my guess was, that the service has to register with netbird service -k <key> instead of netbird up -k <key> and I tried running that manually.

Starting the service with the key worked and showed status "running". GUI also switched to "green" and could stop/start without problems. So I guess the problem is the initial setup that has to be done with the `service` keyword, not with the `up` one?`

Cheers!
#72
25.7, 25.10 Legacy Series / Re: Netbird plugin won't start
September 12, 2025, 04:29:50 PM
Quote from: franco on September 12, 2025, 04:07:01 PMhttps://www.reddit.com/r/opnsense/comments/1nezozf/comment/ndsqg3p/

Thanks Franco,

but as the original Reddit user seems not to have opened an issue (didn't find one when searching), I opened one as requested. Also I'm in touch with Netbird devs and shot them the log and description, too.

https://github.com/opnsense/plugins/issues/4934

If you can point me to a thing, I can do to get more debug details as to why the agent won't start, fire away, happy to test/help.

Cheers
\jens
#73
25.7, 25.10 Legacy Series / Netbird plugin won't start
September 12, 2025, 01:28:12 PM
Hi,

tested the new Netbird integration and tried my test setup key but the service won't start at all:

Quote[cf80a216-e515-45cc-acc1-a3cf1899ed2c] Script action failed with Command '/usr/local/bin/netbird up -m 'https://api.netbird.io:443' -k '22BCF562-xxxx-xxxx-xxxx-1CA4723CC26B'' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 78, in execute subprocess.run(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.11/subprocess.py", line 571, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '/usr/local/bin/netbird up -m 'https://api.netbird.io:443' -k '22BCF562-xxxx-xxxx-xxxx-1CA4723CC26B'' returned non-zero exit status 1.

Also the plugin doesn't log its own errors in its tab (most likely because the messages were thrown from controld and not netbird itself).

Cheers,
\jens
#74
Quote from: Freggster on July 27, 2025, 07:12:36 PMBei alle Youtube Videos die eine OpnSense auf einen Promox via VM einrichten, erscheinen die Intefaces korrekterweise WAN (vtnet0) und die LAN (vtnet1)

Dann sind die Tutorials wahrscheinlich alt. Neue OPNsense Versionen machen immer das erste Interface zum LAN, das zweite zum WAN. Das hat sich in einer Version mal getauscht (man entschuldige dass ichs nicht mehr auswendig weiß welche :)) aber das "Autosetup" erkennt das erste (vtnet0) eben als LAN und das zweite (vtnet1) als WAN. Einfach so im Proxmox anpassen/ändern, dann gibts weniger Streß. Ansonsten kannst du nach Booten natürlich wie @viragomann sagt auch einfach die Interfaces anders herum mappen. Das ist ja nicht in Stein gemeißelt :)

Cheers
#75
Quote from: spraysn on July 27, 2025, 08:18:06 PM1. Ist Unbound für externe Auflösung und DNSmasq für interne Auflösung zuständig?
Nein, das sind zwei Werkzeuge. Unbound ist ein DNS Resolver - der löst selbst DNS über die Root Server auf. DNSmasq ist ein Forwarder, der schickt nur alles an irgendeinen DNS Server (oder mehrere) draußen weiter. Ich persönlich bin kein Fan von Forwarding, weil ich mich dann verlasse auf das was der Forwarder mir sagt und das wieder zentralisiert, was dezentral sein sollte. Was du tust, liegt ganz bei dir und deinen Vorlieben. Beide laufen aber theoretisch auf dem gleichen Port also entweder - oder. Der Umbruch der stattfindet ist lediglich der default, und da DNSmasq auch DHCP spielen kann, ist das für kleine Setups vielleicht einfacher (ähnlich wie Pihole). Ich bevorzuge klar Unbound für DNS und was anderes (Kea, ISC, Dnsmasq, egal) für DHCP. Je nach Bedarf.

Quote from: spraysn on July 27, 2025, 08:18:06 PM2. Wie kann ich statische IP-Adressen im internen Netzwerk automatisch bei DNS eintragen lassen? Oder muss ich das manuell machen? Ich kenne es nur manuell.

Wenn es um IPs geht, die Geräte via DHCP fix haben (static reservations), die können in DNS mit reingeladen werden. Hängt aber von DHCP/DNS Kombo ab. Wenn es um völlig getrennte IPs geht (Geräte statisch konfiguriert), dann kann man sowohl Unbound als auch DNSmasq über Host Overrides problemlos Einträge dazukonfigurieren. Oder du machst dann das große Fass auf und machst bspw. das Bind Paket mit rauf und machst eine eigene interne Domain mit DNS Server. Was du da vor hast, weiß ich ja nicht :)

Cheers
\jens