Woooow!!

Ich hätte niemals mit so vielen, netten und detailreichen Lösungsansätzen gerechnet! - Vielen Dank! - Ihr seid der Hammer!

Da die einzelnen VLANs/Subnetze schön separiert sind und es keine Überlappungen gibt, werde ich den Weg mit Tailscale mal versuchen. - Was mir an Tailscale oder Headscale leider wenig gefällt ist, dass der Traffic dann auf einer Ziel pfsense mit der lokalen pfsense IP genattet wird. Soweit ich weiß kann man die Firewallregeln im der Tailscale Cloud (Webpage) fein anpassen, aber die Source IP Adresse sehr ich dann leider wieder nicht, was speziell bei Logfiles oder fail2ban sicher wieder andere Probleme verursacht.

Hat hier jemand noch eine Idee? Soweit ich gelesen und verstanden habe, ist das aber bei der pfsense mit Tailscale immer so. (durch die Implementierung im System?!

@chris_6n said in DNS Auflösung im LAN:

Jetzt läuft wieder alles. Warum kommt da so eine komische Empfehlung.

Och Kinners!

@chris_6n said in DNS Auflösung im LAN:

Ja ich nutze KEA DHCP. Das stand auf irgendeine pfsense Website.

V
1 Antwort Letzte Antwort vor 9 Tagen Antworten

NEIN, stand es NICHT. Da steht, dass KEA in einer PREVIEW Version enthalten ist, die noch Dinge NICHT kann, die DHCPd tut und auch genau welche. Und dass DHCPd lediglich EOL ist also nicht weiterentwickelt wird. Da stand aber mit keinem Wort, dass man KEA jetzt einsetzen muss/soll, sondern lediglich, dass jetzt mit Kea ein Nachfolger für ISC DHCPd mit im Spiel ist, der aber erst noch ordentlich ausgebaut werden muss. Selbst im Dialog wo man KEA einschaltet, steht, dass da NUR die most-requested Features drin sind bisher. Nicht alle.

Lest doch bitte die Release Notes vor einem Update richtig und nicht nur in Dialogen "oh neu, muss ja." Wieviel Supportfälle ich allein wegen diesem Punkt hatte, geht echt auf keine Kuhhaut.

e5d6eaf2-a6a3-499a-8fa1-72feb2551b34-image.png

Nur weil Sie die Info eingebaut haben (wie auch bei OpenVPN shared key tunnels), dass der ISC DHCP in irgendeiner zukünftigen Version wegfällt steht da nicht "jetzt umstellen!" 😄

@mansior said in OpenVPN Site2Site Verbindungsproblem:

@viragomann
wenn ich die Anleitungen richtig verstehe, dass hat OpenVPN nochmal sowas wie eine eigene Routing Tabelle... ich hatte Client Specific Override ausprobiert und dort eigentlich das gleiche wie beim Server eingetragen... Das hat leider nicht geholfen...

Ich muss gestehen, dass mir das, wahrscheinlich wegen mir, zu lange dauerte und ich deswegen jetzt auf Wireguard geschwenkt bin...das läuft nu wie ich es wollte.

Trotzdem vielen Dank für die Mühe!!!

Wireguard hat wieder seine ganz eigenen Baustellen.

Was OpenVPN braucht ist einfach:

Site2Site mit Zertifikat beide Seiten haben ihre lokalen und remote Netze befüllt. CN der Client Seite bekommt auf dem Server eine CSO in der nochmals die Remote Seite ausgefüllt sein muss!

Wenn das gegeben ist, klappt es auch mit der Verbindung. OVPN hat da keine besondere zusätzliche Routingtabelle, es ist schlicht die Routinglogik die nicht eindeutig ist:

Du konfigurierst den Server auf Seite A, Client auf Seite B Seite B kann sich NUR zu Seite A connecten - da gibt es keine Frage Seite A Server kann aber MEHRERE Clients haben. Niemand verbietet das und das Setup ist auch nicht unüblich, wenngleich ich es nicht empfehle. Aber im Gegensatz zum alten Shared Key Tunnel gibt es hier eben NICHT eine eindeutige Klarheit, wohin Pakete geroutet werden sollen, denn es kann X Clients geben die verbunden sind.

Daher gilt hier:

Remote Netz im Server selbst: Hier müssen ALLE Netze hinein, die sich ggf. mit Clients verbinden. Wenn das mehrere S2S Clients sind, müssen das ALLE Remote Netze sein. Und daran sieht man schon, dass es nun schwer wird zu wissen, wo die Netze hin sollen. CSO mit Match auf Zertifikats-CN des Clients für den richtigen Tunnel: Hier im Remote Netz muss dann NUR das Netz stehen, dass auch wirklich auf der Client Seite zu finden ist.

Dann kann der OVPN Serverprozess auch verstehen, WAS er alles annehmen soll und an WEN er dann WAS weitergeben soll.

Darum braucht man es auch bei nur einem Client eben 2x definiert 😄

Cheers

@viragomann

Hallo ich noch mal - sag mal kennst du dich mit ESXI aus? Die ganze Aktion gestern lief nicht auf ESXI sondern auf einem anderen Hypervisor von Synology (Virtual Machine Manager = VMM). Ich hab zwar im ursprünglichen Posting geschrieben dass die Testumgebung auf ESXI läuft....hatte es dann aber in einer zweiten Umgebung auf VMM mit deiner Hilfe zum Laufen gebracht.

Ehrgeizig wie ich bin wollte ich es heute auf ESXI (nach deiner Anleitung von gestern) zum Laufen bringen. Auf ESXI hab ich nämlich mehr Hardware-Resourcen als auf VMM (viel mehr Arbeitsspeicher und CPU-Power)

Hier hab ich aber das Problem das pfSense überhaupt kein Kommunikation im WAN-Netz mit den beiden VMs hat - also Ping von und zu pfSense funktioniert nicht - während Ping zwischen den VMs funktioniert einwandfrei

Guckst du hier (die beiden VMs heissen "Anmeldung" und "Isyserver"):

Bildschirmfoto 2024-01-28 um 12.28.26.png

Update: Hat sich schon erledigt! ich hatte in pfSense die "Leitungen" vertauscht....also WAN entsprach der vmx0-Leitung - die aber in ESXI nicht als WAM sondern als LAN definiert war ....hab in pfSense über "assign Interfaces" einfach die Leitungen vertauscht --> WAN hat jetzt die vmx1-Leitung ....und alles ist gut !!! 😊 Schönen Sonntag noch !!

@dreamerxch

Moin,

Hast Du einen kleinen Server, wo Du was installieren kannst? Dann wirf mal einen Blick auf UptimeKuma.
Eine Anleitung findest Du hier: administrator.de Anleitung UptimeKuma installieren

Gruß teddy

@bahsig said in Bintec-VPN Site-to-Site hinter pfSense:

LAN: 172.31.0.0/22
Entferntes LAN: 192.168.152.0/23

Wenn nun der Bintec Paket mit Zieladresse in 192.168.152.0/23 auf die pfSense schickt, dann hat er keine VPN aufgebaut, oder sie ist falsch konfiguriert. Das sollte auch der entfernte Admin verstehen.

Ich kann auch nicht nachvollziehen, warum der Admin der Meinung ist, dass er auf seiner Seite sämtliche Routen zu uns umschreiben muss,

Das einzige, was anders einzurichten wäre, könnte die lokale IP sein. Aber wenn er nur ein klein wenig schlau ist und dir auch was zutraut, dann konfiguriert er die Schnittstelle für DHCP. Dann ist die IP unter deiner Kontrolle, wie es sein sollte.
Ansonsten hat er nur die IPSec einzurichten mit einem Tunnel für die beiden Seiten und die öffentliche IP, mit welcher er sich verbinden soll.

Dann ist es völlig egal, ob er im selben Netz wie die Zielgeräte liegt oder nicht. Ist er es nicht (Transitnetz) routet er dein lokales LAN eben auf das dafault Gateway, das er auch vom DHCP mitgeteilt bekommt.

@CrazyWolf-0 said in Altes WAN iface kann nicht ausgesteckt werden:

@fireodo War tatsächlich das Problem, Vielen Dank!

Freut mich! Gerngeschehen!

Ja ich nutze nur den pfBlockerNG hier.

@n300 der umgekehrte Fall trifft zu, das Modul hat aber auch nichts mit den Client zu tun, sondern mit Übermittlung von Domains via pfB wenn das gemeint ist.

@DasBrot Kann ich ohne weitere Punkte schlecht nachvollziehen. Haben hier aber zum Test auch im Lab mehrere Kisten und die updaten und neustarten sich ohne Problem auch mit Wireguard neu, daher wäre es seltsam dass das jetzt alle betreffen würde. Dann gäbe es aktuellere Meldungen dazu. Das klingt eher nach einer seltsamen Konfiguration?

Cheers

@Artefakt Von dem was ich da lese ist das IMHO falsch. Vielleicht ist das beim Apfel wieder ne Sonderlocke, aber ansonsten halte ich das für Unfug, was da geschrieben steht.

Was enforced und später wieder abgeschwächt wurde (AFAIR) ist, dass die Androiden - und auch Apple - den Radius nicht mehr einfach benutzen, wenn das Zertifikat nicht bekannt ist bzw. die Kette.

Sofern das Zertifikat aber von einer CA stammt, mit dem die Geräte fein sind, ist das kein Problem. Warum in dem Thread jemand Zertifikat nach USERNAMEN baut und das irgendwie zusammenbastelt - keine Ahnung, aber das hört sich nach grobem Unfug an. Was IMHO stimmen muss ist:

CA und Serverzertifikat müssen passen was Laufzeit angeht CA muss im Telefon eingespielt sein wenn sie selbst ausgestellt ist. Das bieten die Androiden auch alle an. Ist die CA im Telefon enthalten, kann auch das Zert ordentlich abgenickt werden Beim WPA2ENT Profil muss das Zertifikat der CA ausgewählt sein und als Domain dann der Name, den das Radius Cert hat - also bspw. "server-radius" Identity ist der wpa2 Username der via Radius geprüft wird. Anon Identity ist irrelevant. Password logischerweise das Passwort des Users in Identity PEAP/MSCHAPv2 sollte da als Modus problemlos laufen man geht auf "CA certificate" -> "Install certificates" und installiert sich im Handy das Stammzert - also die CA. Wenn die 10 Jahre Laufzeit hat was die pfSense ja Standard macht, hat man da ziemlich lang Ruhe. Bei Cert Status "Do not verify" damit es nicht extern geprüft wird - ist ja intern.

Fertig. Habe hier sowohl zum Test ein Pixel 6 mit Android 12 noch (weil zu faul gerade zum Updaten gewesen) und eines mit Android 14 auf latest Stand. Beide funktionieren so perfekt ohne Probleme.

Und selbst angebissene Äpfel habe ich hier schon mit Hilfe des Zerts einspielen problemlos zum Laufen bekommen. Wüsste also nicht was man da mit pro User Zertifikaten und Geraffel anstellen soll, wenn das überhaupt nicht übermittelt bzw. geprüft wird. Sehr dubios.

Cheers :)

So, kurze Auflösung: Die Primary hing netzwerktechnisch tatsächlich irgendwo zwischen Himmel und Hölle fest und konnte der Backup trotzdem irgendwie signalisieren: "Ich zucke noch...". Nachdem man ihr den Gnadenschuss gegeben hatte (Power off) sprang die Backup auch gleich auf Master um. Die Masternode wieder hochgefahren, hat diese ihre ursprüngliche Rolle als Primary auch gleich wieder wahrgenommen!

Alles wieder gut! Danke!

Hallo zusammen,

ich danke Euch für die Antworten. Ich habe jedoch die beschlossen, die pfSense auszumustern und auf Sophos zu wechseln. Over all ist die Performance im Netz deutlich besser und konstanter geworden.

Vllt kreuzen sich die Wege noch einmal, wenn die Entwickler auf ein anderes Grundgerüst wechseln.

Grüße
Arne

@JeGr Danke Dir! VG Sutti

pfSense ist eine richtige Firewall, aus dem Enterprise Bereich und ist mir persönlich lieber also ein Router von einem Youtube Bastler, vor allem wo die Basis hier FreeBSD ist.
pfSense braucht aber auch gescheite Hardware auf der sie läuft.

Oder meinst du eine Lösung wie Cisco sie anbietet, bei der du dann an den Hersteller gebunden bist, klar kann man sich auch kaufen, aber dann sprechen wir von laufenden Kosten, sonst nix mit Updates und die sind um Faktor 10 höher als einmal eine gescheite Netgate Appliance zu kaufen, fallen aber Jährlich an.

@esquire1968-0 said in Probleme bei Neuistallation v2.7.2:

unable to figure out a UUID from DMI data, generating a new one

Das ist nix wildes:
https://forum.netgate.com/topic/141691/defect-etc-rc-d-hostid-file-for-zfs-not-generated-from-uuid/5

Ich bin immer noch mit meiner eierlegenden Wollmilchsau dran.
Kann denn jemand von euch ein LTE Modem empfehlen, das per USB angebunden wird?
Oder konnte schonmal jemand das Huawei E5573 erfolgreich einbinden?

Freue mich auf Tipps.

@be1001 said in OpenVPN von pfsene to Mikrotik Version 6 bzw. Version 7:

Nach dem Update auf 2.7.1 bzw. mittlerweile 2.7.2 bekomme ich kein OpenVPn mehr zum laufen.

Was sagt denn die Log?

Ist es das Problem?
https://forum.netgate.com/topic/185282/openssl-error-0a000076-ssl-routines-no-suitable-signature-algorithm

Mittlerweile habe ich das Problem finden können. Und es lag tatsächlich nicht an der Telefonanlage. Es betraf auch nicht nur die OpenVPN-Roadwarrior, sondern auch die per WireGuard eingewählten. Zusätzlich betraf es auch mehrere VoIP-Softwares wie Phoner und MicroSIP.

Ich musste unter Firewall -> NAT -> Ausgehend jeweils für jedes VPN und jedes Lokale Netz noch eine Regel erstellen.

Etwa so: Schnittstelle: OpenVPN1 Quelle: LAN subnets * * * Adresse: OpenVPN1 address

Warum es vorher ewig (bis Update auf 2.7.0) ohne diese Regel(n) ging verstehe ich nicht ganz. Aktuell läuft schon die 2.7.2 und alles läuft tadellos.

@JeGr Danke erstmal für die Rückmeldung. Leider lässt die Telefonanlage bezüglich Fragmentierung, MTU usw. keinerlei Änderungen zu. Gerade mal den RTP-Portbereich kann man hier variieren. Daher habe ich die Fehlersuche auf die pf begrenzen müssen.