@JeGr said in pfsense HA an Telekom Glasfaser Anschluß: Meinst du eine statische v4/v6? Oder einfach nur DualStack? DualStack Die Frage ist, ob es hier sinnvoller ist, die pfSense VM(!) als HA auszulegen oder einfach deinen Proxmox - von dem du ja anscheinend 2 hast? - nicht einfach so zu konfigurieren, dass du die VM Live migrieren kannst und damit einfach Redundanz über die Hypervisoren hast. Natürlich kann man eine zweite VM machen. Aber wenn du sauberes Backup der VM, Snapshotting via VM und Redundanz über die HV hast, wäre es eigentlich leichter, das in der Schicht darunter zu regeln, als die pfSense mit HA zu nutzen. Proxmox HA vernünftig aufgesetzt sind 3 nodes minimum, da man mit 2 nodes bei Ausfall kein Quorum (Mehrheit) zustande kommt und der Cluster read only geht (also die vms laufen, aber man kann nicht migrieren oder neue starten). Das kann man jedoch händisch "arbeitsfähig bleiben" (expected 1), wenn 1 node down ist. Da ich meinen potenten Haupt-PVE-Server nicht in dein Cluster bringen will, auch nicht die beiden pfsense PVE ständig online, würde ich dann zu einem "degraded" cluster Betrieb tendieren. Bei bedarf fahre ich den 2. node hoch, migriere die VM, expect 1 setzen und fahre den 1. node runter/führe dort die Wartung durch. Danach alles zurück migrieren, node 2 wieder down Ein 3 Port WAN VLAN auf einem Switch und da dann Modem uplink, WAN Node 1 und WAN Node 2 dran. bei Life Migration dürfe dem Modem dann der Wechsel des nodes nicht auffallen (selbe Mac WAN pfsense) Das müsste gehen. Hub dazwischen wäre doch dann simpler? Wenn du also nicht das Glasmodem durch einen Router davor austauschen/umkonfigurieren möchtest Das Szenario hatte ich auch schon, dann läuft aber entweder ein Router statt dem Modem oder ein Modem, 1 Router, 2 PVE. Double NAT hat man so oder so, das wollte ich vermeiden. Der erste Router müsste dann ja auch auf "Durchzug" stehen und alles durchreichen. Wenn du noch Fragen hast, gern :) Cheers! Danke! Wenn mein Gedanke zum "downgraded" Proxmox Cluster mit 2 Nodes und VLAN für sauberen WAN switch bei Migration sauber funktioniert aus deiner Sicht, wäre das mein Weg, den ich teste. Danke sehr für deinen Input und den Denkanstoß Grüße!

@johndo Das System Log zeigt jedenfalls einen Gateway-Alarm. Soweit ich diese kenne, hängt das mit dem Monitoring zusammen. War das also vor Deaktivieren des Gateway-Monitorings? Das DHCP Log zeigt für mich einen normalen DHCP Request mit Antwort vom Server und eine Zuweisung der erhaltenen IP. Daher frage ich mich, ob das Log Schnipsel überhaupt was mit dem Ausfall zu tun hat. Es ist auch eine andere Log-Zeit als der Gateway-Ausfall. Ja, die 10.211.0.254 müsste der DHCP Server des Providers sein. Der kann in seinem eigenen Netz auch eine private Adresse nutzen.

@JeGr mein Ruf ist zu "schlecht" für einen echten Daumen hoch für diesen Thread. Also so... Danke Jens, Viele Grüße, Jörg

@Armin_ said in Konfiguration einer pfSense am Deutsche Giganetz MyNet 600: /var/etc/pppoe_restart_pppoe0 gibt es bei mir nicht Gibt es vermutlich erst, wenn du in Interfaces -> WAN -> PPPoE Configuration ein Custom reset eingerichtet hast. Dann erscheint das als eigener Punkt unter den Services -> Cron -> Settings [2.8.1-RELEASE][admin@pfSense.localdomain]/root: less /var/etc/pppoe_restart_pppoe0 #!/bin/sh /usr/local/sbin/pfSctl -c 'interface reload wan' /usr/bin/logger -t pppoe0 "PPPoE periodic reset executed on wan"

@michaeljk said in Glasfaser mit APU2E4 - welcher Durchsatz möglich?: Fazit: Am 600/300 Anschluss erfüllt die APU2 noch ihren Zweck. Vermutlich wird dies am 1000/500 Anschluss nicht mehr der Fall sein, das prüfe ich dann nochmals bei einem zukünftigen Upgrade. Vor allem wenn die Box PPPoE selbst macht wird es da kritisch bei mehr als ca. halbem Gigabit. Auch wenn der neue Daemon potentiell weniger Overhead hat, ist die Lebenszeit aber langsam erreicht :) Für DSL tuts noch ;) aber schnellere Anschlüsse sollte man dann sich doch lieber in Richtung N150/vergleichbar oder höher orientieren. Cheers

@Rico Ich glaube jetzt hab ich es, das System bootet automatisch vom Stick und über die Serielle Verbindung kann ich die Installation auch starten (xterm war das Mittel der Wahl bei der Konsole, für mich) und werde durch die Installation geführt. Ich hoffe ich kann mein Backup dann auch wieder einspielen

@Woodsomeister Hi Vielen Dank für den Tipp... Ja das ist eine sehr gute Frage warum ich den VMs nicht trauen kann ... Das sind Webserver ein colaboration Server und ein virotualisiertes Synology.... Ich habe aktuell am ehesten das Synology in Verdacht... In den Web Serverogs und den ssh logs ist nix ungewöhnliches zu sehen ... Wie gesagt am ehesten das Synology oder einer der Webserver.... Ich schaue mir das an Ich melde .ich wieder

@Bob.Dig THX.. Probier ich aus..

@wuesti Ach Vertipper, die kommen vor :)

@gtrdriver said in Fallback bei GW Groups ?: Wie kann ich denn erreichen dass Seite A regulär eine Verbindung zum WAN1 auf SeiteB aufbaut und wenn WAN1 auf Seite B offline ist dann Wan2 auf Seite nimmt ? Gibt es dafür irgendeinen Mechanismus ? Das hängt davon ab welches VPN man nutzt. :) 1a) IPsec: schwieriger. Multiple Phasen mit gleichen Settings sind nicht parallel nutzbar. Man müsste also zwei VTI (routed) IPsecs bauen und über deren Transfernetze dann sowas wie OSPF sprechen. Früher gabs das noch mit Failover Gateways + Static Routes aber statische Routen können nicht (mehr) auf GW Gruppen aufgelegt werden da das irgendwelche seltsamen Nebeneffekte hatte. Ginge also nur entweder mit OSPF oder vielleicht dann policy based rules mit nem Failover GW über beide VTI Gateways auf beiden Seiten. Müsste man mal testweise bauen um das zu bestätigen. Aber so richtig schön nicht. 1b) IPsec: fummliger. Andere Möglichkeit statt 2 Tunnel wäre ein Tunnel, der statt gegen statische IP stattdessen gegen einen FQDN aufgebaut ist. Den kann man auf einen DynDNS Namen legen und auf Seite B dann einen Job einrichten, der bei Ausfall WAN1 die Adresse von WAN2 in den DynDNS Namen pusht. Dann baut die andere Seite bei < DNS TTL die Verbindung gegen die neue IP auf. Haben wir so tatsächlich schon mal umgesetzt. Läuft, hat aber etwas verzug, weil der DNS Push natürlich laufen muss, sonst klappts nicht. Aber wenn beides Sensen sind und da beide Seiten den Tunnel ja aufbauen können, kann es auch sein, dass dann Seite B via WAN2 initiiert und die andere Seite nur abnicken muss. Das klappt dann relativ zeitnah. Nicht sofort instant, aber in vernünftiger Zeit. Ist eben nur fummliger aufzusetzen. OpenVPN: Da ist es easy was das Failover angeht. OpenVPN kann direkt mit mehreren remote statements konfiguriert werden, hat also Alternativwege schon eingebacken. Lediglich wenn auf Seite B WAN1 wiederkommt, gibt es kein automatisches Fallback. Dazu müsste der Tunnel kurz neugestartet werden. Das ist das einzige kleine Manko. Machen aber viele Firmen trotzdem so und monitoren einfach, mit welcher Gegenstelle verbunden ist und wenn WAN1 auf B wieder da ist wird kurz auf Seite A der Tunnelaufbau neu angestoßen. 1-2s und alles rennt wieder auf WAN1 statt 2. Wireguard. Wenn kein Cluster involviert ist macht WG ja eh was es will und spricht auf allen Interfaces. Wenn die Gegenseite nicht explizit auf WAN1 beschränkt ist und WAN1 ausfällt wird WG von sich aus via WAN2 weiterquatschen und sollte auf Seite A dann auch angenommen werden, weil Key/PSK und Co stimmen. Dann lernt die Seite dass sie jetzt mit WAN2 kommuniziert. Wenn WAN1 wiederkommt, switcht es ggf. sogar zurück. Sehr nett. Hat aber wie gesagt dann andere Problemchen wenn Cluster oder gezielte WAN Nutzung ins Spiel kommt. Overlay VPNs. Also Tailscale, Netbird und Co. Bei denen ist es stark abängig wo der Endpunkt auf beiden Seiten läuft und wie sie konfiguriert sind. Aber da hier die Endpunkte mit der Control Plane sprechen und das primär ne ausgehende Verbindung ist, klappt die Verbindung da eigentlich immer und sollte bei Failover auch korrekt via anderen IPs sprechen. Solange die Standorte Netz haben, kommen auch die Clients raus und können ne Verbindung bauen. Je nachdem wo diese laufen kann man das dann steuern welches WAN sie nutzen. Cheers :)

@paolo256 said in Hilfegesuch bei Telekom VDSL Anschluss mit VIGOR167 und pfSense: Ich nehm den MSS Wert mal raus und schau weiter. Aufgrund des Threads habe ich das mal gemacht und längere Zeit laufen lassen, es kommt wieder zu Problemen das manche Seiten sich per IPv6 überhaupt nicht, oder nur sehr langsam öffnen (z.B. ac-foto.de oder forum.qnapclub.de). Auch wenn es nicht logisch ist, bei mir muss der MSS Wert wieder rein, damit funktioniert der Zugriff per IPv6 reibungslos.

@fireodo said in Hohe CPU Last seit Update auf Version 25.07: Die KEA Implementierung scheint noch etwas (Entwicklungs-) Zeit zu brauchen. Jein, da haperts eher an der Kea-Unbound Interop Geschichte, weniger an Kea. Als reiner DHCP Server ist das fein. Aber die "wir klappern alles in DNS" Sache ist nicht ganz sauber. Allerdings hatte ich subjektiv auch vorher nie den Bedarf, meine Clients in DHCP reinzuhobeln, wenn man den ganzen DNS Integrationskram raus lässt sollte das auch OK sein.

@gtrdriver said in VPN Performance bei S2S: 1: ist es korrekt dass es reicht die MTU mittels mssfix oder tun-mtu nur auf der client Seite anzupassen ? - Die Server Seite bleibt unberührt in der config ? Man kann es an beiden Seiten ändern, wenn der Server es ändert, dann gilt das aber gleich für alle Clients. Bei S2S Tunneln kein großes Thema wenn da ein Server pro Tunnel läuft, für Roadwarrior eher suboptimal, weil da jeder was anderes gern hat. Daher ändern wir das meist testweise auf Clientseite und arbeiten uns da Stück für Stück ran, ob es was bringt. @gtrdriver said in VPN Performance bei S2S: 2: Welche Durchsätze hast du in der Praxis mit OpenVPN erzielt wenn die MTU gut angepasst ist ? Wenn keine seltsamen Sachen am Start sind, die zwischen den zwei Providern Streß machen, haben wir je nach Hardware schon mehr als ordentliche multi-hundert-Megabit Strecken gehabt. Ja mit OpenVPN. Nein, kein Wireguard. Ja, das ist machbar :) Aber eben stark abhängig zwischen den Standorten und was da an Peering, Providern und sonstwas dazwischen quer hängt. Wie gesagt, wir hatten das schon, dass ein Providerwechsel auf Clientseite die ganze Tunnelperformance gekillt hat. Erst nach Switch auf TCP und kleinere MSS war das wieder halbwegs hinnehmbar. Da weiß man leider nicht, was die da treiben, ob die mit irgendwelcher BlackMagic(TM)-Detection-BS irgendwelches Shaping oder dePriorisierung machen oder oder oder. @gtrdriver said in VPN Performance bei S2S: 3: Spricht aus deiner Sicht irgendwas gegen oder für wireguard ? Hängt STARK vom Einsatzzweck ab. Zwei Seiten mit lediglich einer Sense am jeweiligen Ende? Hab Spaß :) Für Homelab/daheim? Hab Spaß oder versuchs ruhig, kein Ding. Für Cluster oder Business? Meh. Wireguard schwebt abgehoben irgendwo im Kernel über den Interfaces und lässt sich nur schwer auf eine bestimmte IP quetschen. Das ist räudig. Wenn man also gezielte Steuerung des Tunnels haben will auf einem bestimmten WAN oder mit einer bestimmten Adresse ist WG mitunter das Werkzeug aus dem 7. Kreis der Vorhölle. Wird dran gebastelt, aber aktuell gibts da nichts wirklich schönes außer mit vielen Regeln und Co den Empfang/Senden zu verbieten, eher nicht so geil. Oder wenn du eindeutige User-Auth machen möchtest von Benutzern bei der Einwahl in ein VPN. WG kennt keine User. Nur Peers. Gegenstellen. Geräte. Das ist KEINE User Authentifizierung, sondern Geräte die sich anmelden. Ob es der User ist - keine Ahnung. Das wäre äquivalent zu OpenVPN mit Zert ohne User+Pass mit Auto-Einwahl. Wird auch nur das Gerät authentifiziert, aber keine Details vom Benutzer. Anbindung an sowas wie LDAP, AD, Radius o.ä. ist auch nicht drin, daher nett, aber im Unternehmenskontext einfach schwierig bis nicht sinnvoll direkt einzusetzen. Neue ZeroTrustAccess VPNs die darauf aufsetzen, wie Netbird, Tailscale etc. sind dann wieder ne andere Sache, denn da übernimmt eben die ZTA Schicht drüber (Control Plane von NB/TS bspw.) die Auth und die Geräte IDs und kann damit dann direkt umgehen, MFA machen, etc. etc. Also als Technik: fein. Als VPN: in Maßen, je nach Einsatzzweck OK. Als Unterbau für ZTAs: sehr cool. Cheers

@gtrdriver Hallo, auf A braucht das erst mal die Route zu B (VPN Gateway). Dazu musst du erst der VPN Instanz ein Interface zuweisen. Damit erhältst du auch ein Gateway, auf das geroutet werden kann. Das Routing sollte wohl mit einer Policy-Routing Firewall Regel gemacht werden. Hier kannst du bspw. den Traffic eine bestimmten Quelle oder zu einem bestimmten Ziel (im Alias definiert) oder beides routen. In den Advanced Options der Regel kann das Gateway angegeben werden. Die Regel muss ganz nach oben geschoben werden, damit sie vor andren zutrifft, die ausgehenden Traffic erlauben. Auf B brauchst du eine Outbound NAT Regel am WAN für die Quelle-IP (od. bspw. das A LAN Subnetz). Dafür muss du den Hybriden Mode aktivieren. Grüße