@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.

@micneu Das Problem hat sich "gelöst":
Ich habe von der Telekom die neue Magenta Box One bekommen. Diese ähnelt dem Apple Tv.
Es läuft jetzt einwandfrei. Die Magenta Box 401 so die Aussage wird verschwinden, somit auch die Problematik mit dem Multicast in pfSense.
Danke für die Hilfe bis hier her!

Kurioser Fakt am Rande, die Fernbedienung der Magenta One schaltet auch eine PS5 ein.

Ich habe hier 13 VLANs und alle laufen als 802.1ad, QinQ ist schon speziell und hat seine Anwendungsfälle aber das per default zu setzten ist schon stark.

Bei der pfSense ist QinQ ein eigener Bereich, VLANs werden in einem anderen Reiter angelegt und sind immer 802.ad.

Aber, eine SPI Firewall, egal welcher Hersteller, hat immer Probleme mit asymmetrischem Routing.
Aus dem Grund wird ja auch immer ein Transfernetz empfehlen, über dieses redet dann die Firewall mit allem auf der Gegenstelle.

In dem Fall würde das bei dir so aussehen, eine Default Route auf dem Switch mit 0.0.0.0 0.0.0.0 auf die IP der FW im Transfernetz.
Von der FW aus das CIRD Netz auf Switch Seite zu ihm routen, also so was wie 192.168.0.0 255.255.0.0 auf die IP vom Switch im Transfernetz.

Dann ist aber nix mit VLAN Sup Interfaces auf der Firewall, wenn du das machst, dann hat du keine saubere Netzstruktur mehr und Pakete vom Client laufen über den Switch zur FW, dann ins Internet und wieder zurück. Jetzt aber von der FW direkt zum Client, da gibt es aber keinen State Eintrag und damit wird das Paket verworfen.
Kann man über eine Regel erlauben, dann wird ein neuer State aufgebaut, aber dann kannst du die Firewall gleich abschalten, denn du müsstest any ip permit auf dein LAN vom WAN aus zulassen.
Ja kann man machen, wenn man einen großen Honigtop aufstellen will, dann kannst aber auch gleich den Switch ins WAN hängen und brauchst die FW nicht mehr.

Du kannst das so aufbauen, wenn alles hinter dem Switch das gleiche Vertrauen genießt, dann kann man hier einfach routen, doch dann hast du keine Firewall mehr dazwischen. Ist ja auch so gewollt, soll mit max Linespeed zwischen den VLANs geroutet werden, das macht dann der Core auch, dafür ist er da.
Doch will man hier was aufteilen, bist du bei Switch ACLs, die nur selten Statefull arbeiten, gibt es auch, aber das mit vollem Backplane Speed wird zum Teil teuer.

Also entweder volle Power beim Routing oder Firewalling mit dem Speed den die Kiste halt hin bekommt, dazwischen gibt es nix.
Aber das hatte dir Patrick ja drüben schon erklärt.

Wenn irgendwelche anderen Kisten das machen, würde ich mir über die SPI Firewall Funktion in den Kisten ernsthaft Gedanken machen, ob ich denen noch trauen würde, vermutlich nur so weit wie ich die werfen könnte.

@JonathanLee

Thanks a lot Jonathan for this examples! I will study them thoroughly in the next days. I wish You a nice Christmas!

@viragomann said in Firewall Destination | "VDSL address" (PPPoE WAN down):

Sollte ja kein Problem sein, oder?

Wenn ich dich richtig verstehe wir die Rule dann erzeugt sobald das WAN online geht, dann wäre es kein Problem.

/tmp/rules.debug kann ich noch gar nicht, danke für den Hinweis!