Hi wenn ich offen sein darf - ich trauere ISDN auch immer noch hinterher ... aber hilft ja nix ... Inzwischen hat sich das ganze etwas geändert - wir planen nun CloudPBX einzusetzten. DAs ist ne Telekom Cloud Telefonanlage bei der Lokal garnix mehr installiert wird - auch die Telefone sind dann von der Telekom mit auto provisionierung Nun stellt sich nur noch die Frage ob ich hier in Verbindung mit Pfsense was beachten muss ... Grüße !

@tpf said in Wireguard S2S MultiWAN als Endpoint: Ich will noch nicht so recht auf OpenVPN umstellen, auch wenns wahrscheinlich einfacher wäre... Warum, wo ist das Problem? Wenn A nicht passt, nehme ich eben B wenn ichs mir aussuchen kann. Warum sollte ich mir das Leben künstlich schwer machen? Gibt genug, was das eh schon tut ;) Und bei MultiWAN ist Wireguard eben notirisch schlecht zu konfigurieren, genau weil es Interface-agnostisch im Kernel agiert und keine echte Interface-Bindung hat. Das macht es in vielen Fällen unnötig schwer, gezielt bspw. WG auf WAN2 zu betreiben wenn WAN1 aber Hauptleitung ist und man trotzdem Failover möchte. Sicher tut sich das was in der Entwicklung irgendwann aber aktuell wüsste ich nicht, wie man das sinnvoll bauen kann, damit es trotzdem sauberes Switching zur gewünschten Leitung hat. Alles was mir dazu zugetragen wurde mit "Sperre den Zugriff auf die andere Leitung etc." sind nur Workarounds und helfen nicht die Verbindung sauber umzuschalten wenn es Probleme gibt. Cheers

@Asulu said in pfSense: TLS-Handshake friert bei bestimmten Webseiten ein: Hallo zusammen, ich stehe vor einem absolut paradoxen Phänomen auf meiner pfSense (Netgate 8200) und brauche frische Augen für das Problem. 25.11.1-RELEASE Das Problem Von meinem Server-VLAN aus laden bestimmte Webseiten (z. B. menuelounge.com) nicht. Der Browser lädt unendlich, ein curl -Iv friert reproduzierbar mitten im TLS-Handshake ein. Aus anderen VLANs (z. B. dem WLAN-VLAN oder einem weiteren kabelgebundenen VLAN) funktioniert der Aufruf derselben Webseiten vom exakt selben Client-PC über das exakt selbe physische Kabel ohne Probleme. Die Umgebung Firewall: pfSense Plus (Netgate 8200), Ausgänge über 10G SFP+ (ix Treiber). Switche: Aruba 2930M Stack. VLANs: * VLAN 3 (ix0.3): Server-VLAN (Hier tritt der Fehler auf) VLAN 30 (ix0.30): WLAN-VLAN (Hier funktioniert es) Alle Interfaces haben identische Firewall-Regeln (Any->Any Testregeln), DNS ist sauber und das Outbound-NAT läuft für alle Netze identisch über Hybrid-Regeln auf das WAN-Interface. Die Packet Captures (Das Paradoxon) Beim genauen Hinsehen im Packet Capture der pfSense zeigt sich, dass im fehlerhaften Server-VLAN (VLAN 3) die ankommenden Paketgrößen vom Webserver mitten im Handshake abgeschnitten werden: Hier funktioniert es NICHT (Server-VLAN 3): Der TCP-Handshake klappt, der Client schickt sein Client Hello (tcp 1440 + tcp 285). Die Gegenseite antwortet, aber es kommt kein Paket an, das größer als 1176 Bytes ist. Danach friert die Verbindung ein. Plaintext 18:38:11.675576 IP 192.168.203.35.51748 > 13.93.53.82.443: tcp 0 18:38:11.707106 IP 13.93.53.82.443 > 192.168.203.35.51748: tcp 0 18:38:11.710466 IP 192.168.203.35.51748 > 13.93.53.82.443: tcp 1440 18:38:11.710482 IP 192.168.203.35.51748 > 13.93.53.82.443: tcp 285 18:38:11.742184 IP 13.93.53.82.443 > 192.168.203.35.51748: tcp 1176 <-- Größtes Paket, danach Ende Hier FUNKTIONIERT es (WLAN-VLAN 30): Gleicher PC, gleiches Kabel (nur am Switch das VLAN gewechselt). Der Webserver schickt hier problemlos Fragmente mit tcp 1452 (was inklusive Header exakt der PPPoE MTU von 1492 entspricht). Der Handshake läuft komplett durch. Plaintext 18:39:51.958333 IP 192.168.230.189.64437 > 13.93.53.82.443: tcp 0 18:39:51.989592 IP 13.93.53.82.443 > 192.168.230.189.64437: tcp 0 18:39:52.001969 IP 192.168.230.189.64437 > 13.93.53.82.443: tcp 1440 18:39:52.033393 IP 13.93.53.82.443 > 192.168.230.189.64437: tcp 1452 <-- Pakete kommen mit Full-Size an Was bereits geprüft/ausgeschlossen wurde: Hardware/Kabel/Client-OS: Da es derselbe PC am selben Port/Kabel ist, können wir NIC, Windows-Schannel-Fehler oder physische Defekte ausschließen. Outbound NAT: Steht auf Hybrid. Die automatischen Regeln greifen für beide Subnetze (192.168.203.0/24 und 192.168.230.0/24) absolut identisch. Switch-MTU: Beide VLANs (3 und 30) sind auf den Aruba-Switchen identisch konfiguriert (Jumbo: No). Sie laufen über dieselben getaggten Trunks (Trk1) zur pfSense. Ein Testweise Deaktivieren des funktionalen Interfaces auf der pfSense brachte keine Besserung für VLAN 3. Hardware Offloading: Ist auf der pfSense komplett deaktiviert (Checksum, TSO, LRO). Jemand eine Idee? Außer das ich jetzt das VLAN mal auf ein eigenes Interface lege weiß ich gerade nicht mehr weiter. Danke Da ist zwar noch etwas wenig Detail mit im Spiel und wir kennen die Config nicht - nicht nur die der Sense, sondern auch Switche und das was im Servernet steht, aber hat der Server ggf. zwei Netzwerkkarten und/oder ist in zweierlei Netzen? Wie sind die Netze/VLANs konfiguriert? irgendwo noch ein anderer Router im Netz? Hat der Server oder das Gerät mit dem du testest im Server VLAN ein anderes GW als die Sense? Alles was "anders" ist zählt. Könnte asymmetrisches Routing sein, anderes GW, zwei Netzwerkkarten und der Traffic läuft falsch rum, etc. etc. - das könnte alles sein. Ohne mehr Details oder das Setup zu sehen ist das schwer. Cheers \jens

@wkn said in pfsense Open VPN Client Verbindung zum Tunnel alle Traffics über einen Gateway: Probiere mal für den Kill-Switch die Option [image: 1779814884607-fe40b0ce-451b-4429-9e86-5ad475ff585d-grafik.png] Das hat defacto ja nichts mit "Kill-Switch" zu tun. Der soll ja eigentlich verhindern, dass Traffic am VPN vorbei blubbert. Stichwort ist da "NO_WAN_EGRESS". Also eine Regel, die Pakete taggt, die eigentlich per VPN geroutet werden sollen/müssen. Und eine zweite, die entsprechend getaggte Pakete auf dem WAN ausgehend verbietet. Die Anleitung liest sich aber steinalt, pfSense 2.7 und 2.8 sind Generationen weiter und das OpenVPN ist auch nicht mehr uralt 2.4, sondern jetzt 2.6 bzw. fast 2.7. Da hat sich etliches getan, wie man sowas sinnvoll und sauber ohne großes Gebastel umsetzen kann. Leider sind diese ganzen VPN Bastelanbieter egal wie groß nicht in der Lage ihre Dokus korrekt zu schreiben oder halbwegs aktuell zu halten. Das letzte Mal dass ich mich bei sowas einlesen musste, war es Nord und dort wurde beim Einrichten einfach mal das Default GW so verbogen, dass das ganze System im Nirvana hing. Alles nicht wirklich sinnvoll :/ Einfacher als das ganze System zu verbiegen ist bspw. das VPN einfach mit "pull-no-routes" anzulegen, das ganze Verbiegen des Default Gateways zu lassen und gezielt das Netz mit den Clients, die nur per VPN online sein sollen einfach mit Policy Based Rules via VPN zu schicken. Wenn man dann noch per Advanced Settings abschaltet, dass Regeln mit Gateway bei Ausfall des Gateways nicht automagisch übers default GW (also WAN) gehen, sondern statt dessen gar nicht ausgeführt werden - hat man auch seinen Killswitch. Per DHCP wird dann für den Client oder das Netz entsprechend einfach ein DNS gepusht, der übers VPN läuft, dann leakt auch kein DNS. Alles was dann noch übers WAN geht ist die pfSense selbst mit System Updates, ihren eigenen paar DNS Aufrufen für Updates und der VPN Verbindung. Wie gesagt, das bekommt man heute wesentlich sinnvoller/moderner hin als das mit den ganzen OpenVPN Quirks von irgendwelchen VPN Butzen kaputt zu konfigurieren. Cheers :)

@kikuyu Vielen Dank, das werd ich mal versuchen :)

@Tobi Perfekt! :) @Tobi said in Probleme mit manches Seiten oder Handy-APPS (nur wenn IPv6 aktiv): Ich habe ihn auf 1492 gesetzt. Ist auch vermutlich der korrekte Wert. :) Ich habe es auch mal angepasst. If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 for IPv4 (TCP/IPv4 header size) and minus 60 for IPv6 (TCP/IPv6 header size) will be in effect.

@nonick Ich habe keine Antwort auf deine Frage, mich interessiert nur, warum du bei der 25.11.1 bleiben willst.

@d4rkw4rden said in OpenVPN kein LAN zugriff: Im Netzwerk ist ein Hyper-V und 3 VMs. Der Domain Controller hat die über eine Nic 2x ips 10.30.3.150/24 und die 192.168.110.2/24. Wo kommt denn jetzt 10.30.3.x her? @d4rkw4rden said in OpenVPN kein LAN zugriff: Mein OpenVPN server ist über LDAP am DC angebunden + User Auth und Cert. Welcher OpenVPN Server? Wo? Wie angebunden an wen? @d4rkw4rden said in OpenVPN kein LAN zugriff: ich kann mich mit meinen Client mit dem OpenVPN CLient verbinden und komme ich mein Tunnel Netzwerk 192.168.187.0/24 und bekomme die IP 192.168.187.2/24 He? Wo ist denn das Subnetz jetzt her und wo stehen Server und Client? Ich bin bei dem Setup maximal verwirrt weil mir nicht klar ist, warum und wohin es hier überhaupt ein OpenVPN gibt, wo das wie konfiguriert ist und in welchem Modus und was das bringen soll? Cheers

Problem hat sich gerade "von alleine" erledigt. ich habe die Sense-Box gebootet, danach die Fritze auch und schon läuft alles :) (Dann kann ich anderen Thread mit eine älterer Kuriosität starten)

@schugk hast du im WAN die Haken bei den „Block …“-Optionen entfernt (ich weiß nicht, was Standard ist, bei mir sind sie gesetzt)? Leider hast du meine weiteren Fragen noch nicht beantwortet – bisher konnte ich nur sehen, dass du VLAN 7 konfiguriert hast.

Jetzt bin ich aber neugierig, was das für eine Umgebung ist, die nicht offline gehen darf und trotzdem PPPoE einsetzt. Die letzte Umgebung, die ich kannte und die nicht ausfallen durfte, war meine alte Firma - dort hatten wir allerdings keine PPPoE‑Verbindung, sondern eine Darkfiber, da durfte auch nichts offline gehen.

@krabat wir sind hier im Deutschen Bereich, @JeGr kann man den in den englischen Bereich verschieben?

Ja, hatte schon einmal vor einem Jahr das Thema. Da habe ich aber nur Infos zu PPPOE bekommen und den Ratschlag Full Dual Stack zu erfragen. Wo es mir drauf ankommt ist das Thema IPv4 im IPv6 Tunnel. PFsense verarbeitet wohl die Info zum AFTR Server nicht automatisch.

@BulkAndi75 said in pfSense und Windows Server DNS: Ich denke aber, für ein kleines Netzwerk, ist dieses Konzept durchaus vertretbar. Mittlerweile habe ich DHCP und DNS über einen Windows DC laufen und funktioniert unter OPNsense ganz gut und stabil. Ich bin aber dabei beide FWs zu testen und pfSense zickt da noch. Definitiv ein setting Thema. Würde ich auch sehen, unserer Lab Erfahrung nach zickt OPN gern etwas mehr als pf in Virtualisierung, da sich die Projekte da etwas unterscheiden. Da sieht man dann auch den unterschiedlichen Unterbau (FBSD 16 inzwischen bei pf). Hängt aber auch stark vom HV ab. KVM (Proxmox, o.ä.) sehe ich eher weniger Probleme. Bei HyperV gabs da schon etwas mehr. Und manchmal hat man auch seltsam ominöse Probleme in kleineren HV Projekten wie Virtuozzo und Co. @BulkAndi75 said in pfSense und Windows Server DNS: Backup und Restore über Veeam geht ruck zuck. Das ist eine Möglichkeit, ich würde aber empfehlen separat dazu noch die config.xml über einen Job zyklisch wegzusichern damit man damit nochmal eine saubere Config hat und als Basis nutzen kann ohne gleich die ganze Maschine wiederherzustellen. Ansonsten ist das klein und fein und sollte ohne große Probleme laufen. Cheers

@Jochen77 du kannst auch deine Domain bei einem anderen Anbieter sehr einfach mit einem Wildcard Zert ausstaffieren und das auch auf der Sense mit ACME. Du brauchst dazu lediglich deine andere Domain, bei der der Check ja sauber funktioniert und kannst die andere Domain bzw. deren acme-challenge dorthin umleiten. Da du die andere Domain ja augenscheinlich via IP64 o.ä. mit Zertifikat ausstatten kannst, klappt das dann via challenge-alias dann auch mit der anderen Domain. Man leitet quasi mit einem CNAME Eintrag die Challenge Abfrage auf die andere Domain um, stellt das im ACME package entsprechend ein und ACME erstellt dann einen sauberen DNS Eintrag zum Prüfen an der richtigen Stelle. Beispiel: DomainA.de - geht problemlos mit wildcard via DNS64 (oder irgendwas anderes mit API) DomainB.de - geht nicht, weil dooferProvider keine ordentliche API hat. Dann erstellt man ein acme-challenge.DomainB.de Eintrag als CNAME, lässt diesen auf acme-challenge.DomainA.de zeigen und konfiguriert in ACME dann einen Job, der Wildcard.DomainB.de anfordert, macht aber einen Haken bei Challenge Alias und trägt dort DomainA.de ein und wählt dann die korrekten API Infos für DomainA ein. LetsEncrypt bekommt dann die Anfrage für DomainB, sieht dass der acme-challenge ein CNAME ist, fragt den Eintrag von DomainA ab und nickt dann entsprechend das Zertifikat für DomainB ab. Klingt kompliziert, ist aber eigentlich recht simpel. Und dann kann man auch problemlos in HAproxy auch alles ordentlich mit Zertifikat und Offloading einrichten ohne Sonderlocken. Cheers

@Kraeuter ja, die habe ich mit meinem Kabelanschluß genutzt, selbe Qualität wie Fritzbox. die Verbindung hatte alle paar Minuten aussetzer. Erst mit dem TC4400 lief der Anschluß stabil. Gruß ré

@snah0815 Nach meiner kurzen Recherche stimmt das so nicht ganz. Schau am besten noch mal in die Dokumentation deines Anbieters, was genau erwartet wird, und lies dir auch den Erklärungstext auf der Konfigurationsseite durch. [image: 1770369559605-scr-20260206-jlso.png] PS: hast du es jetzt hinbekommen? @snah0815 Ist das damit erledigt, oder bestehen noch Probleme?