15
Cronjob für Wireguard unter pfSense und Synchroniserung der GUI
Liebe Gemeinde,
das ist meine zweite Frage zum Thema pfSense in kürzester Zeit. So langsam hat mich das Forum angesteckt.
Die pfSense läuft mittlerweile sehr gut und verwende auch Wireguard. Gerne würde ich Wireguard jedoch nur zu bestimmten Zeiten aktivieren und verwenden. Dafür sehe ich zwei Möglichkeiten:
1.) Über Cronjobs (das Paket kann man ja in pfSense installieren)
2.) Firewall -> Schedules
Darüber hinaus kann ich Wireguard sperren/deaktivieren, indem ich
1.) Den Port auf dem WAN-Interface sperre (bzw. nicht öffnen)
2.) Das Interface deaktiviere
Ich würde gerne das Interface deaktivieren. Das kann ich auch mit einem Cronjob und ifconfig umsetzten, aber dann sehe ich natürlich nicht den aktuellen Zustand in der GUI. Falls ich Schedules in Kombination mit dem Port nutze, so würde es natürlich gehen. Wie mach ihr das (falls für euch relevant)?
das ist meine zweite Frage zum Thema pfSense in kürzester Zeit. So langsam hat mich das Forum angesteckt.
Die pfSense läuft mittlerweile sehr gut und verwende auch Wireguard. Gerne würde ich Wireguard jedoch nur zu bestimmten Zeiten aktivieren und verwenden. Dafür sehe ich zwei Möglichkeiten:
1.) Über Cronjobs (das Paket kann man ja in pfSense installieren)
2.) Firewall -> Schedules
Darüber hinaus kann ich Wireguard sperren/deaktivieren, indem ich
1.) Den Port auf dem WAN-Interface sperre (bzw. nicht öffnen)
2.) Das Interface deaktiviere
Ich würde gerne das Interface deaktivieren. Das kann ich auch mit einem Cronjob und ifconfig umsetzten, aber dann sehe ich natürlich nicht den aktuellen Zustand in der GUI. Falls ich Schedules in Kombination mit dem Port nutze, so würde es natürlich gehen. Wie mach ihr das (falls für euch relevant)?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668833
Url: https://administrator.de/forum/cronjob-fuer-wireguard-unter-pfsense-und-synchroniserung-der-gui-668833.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
15 Kommentare
Neuester Kommentar
Würde stattdessen einfach ne Firewall-Regel mit integrierter Scheduler erstellen die das Forwarding ein und ausgehend über das Wireguard Interface sperrt, fertsch.
1
... also die von mir bereits genannte Lösung (Scheduler + Firewallregel - z.B. auf dem Port).
Arbeitet auch jemand mit der Aktivierung / Deaktivierung des Interfaces? Oder gibt es noch andere/bessere Lösungen?
Arbeitet auch jemand mit der Aktivierung / Deaktivierung des Interfaces? Oder gibt es noch andere/bessere Lösungen?
Zitat von @Frontier:
... also die von mir bereits genannte Lösung (Scheduler + Firewallregel - z.B. auf dem Port).
Arbeitet auch jemand mit der Aktivierung / Deaktivierung des Interfaces? Oder gibt es noch andere/bessere Lösungen?
... also die von mir bereits genannte Lösung (Scheduler + Firewallregel - z.B. auf dem Port).
Arbeitet auch jemand mit der Aktivierung / Deaktivierung des Interfaces? Oder gibt es noch andere/bessere Lösungen?
Die Firewall-Regel ist technisch und richtlinienmäßig schon besser. Warum die Geschichte mit dem Interface?
Grüße
Richard
1Zitat von @Frontier:
... also die von mir bereits genannte Lösung (Scheduler + Firewallregel - z.B. auf dem Port).
Jepp ist zu bevorzugen.... also die von mir bereits genannte Lösung (Scheduler + Firewallregel - z.B. auf dem Port).
Arbeitet auch jemand mit der Aktivierung / Deaktivierung des Interfaces? Oder gibt es noch andere/bessere Lösungen?
Kann man machen wenn man unbedingt will, wenn dich nur der Status in der GU stört, ändere die /conf/config.xml und entferne bzw. füge den <enable></enable> Knoten im Interface hinzu und lösche die /tmp/config.cache dann ist die GUI und config aktuell zu deiner Aktion. Nicht zu empfehlende Frickelei halt.Quick n' dirty bspw. ...
Interface tun_wg0 aktivieren
#!/bin/sh
# enable interface
ifconfig tun_wg0 up
# enable interface in config
sed -rie '/<interfaces>/,/\<\/interfaces>/{s/(<if>tun_wg0<\/if>)/\1\n\t\t\t<enable><\/enable>/;}' /conf/config.xml
# refresh config
rm /tmp/config.cacheInterface tun_wg0 ("opt1" das parent IF bitte auch an deine Config anpassen) deaktivieren
#!/bin/sh
# disable interface
ifconfig tun_wg0 down
# disable interface in config
sed -rie '/<interfaces>/,/<\/interfaces>/{/<opt1>/,/<\/opt1>/{/<enable><\/enable>/d;};}' /conf/config.xml
# refresh config
rm /tmp/config.cache
@150704: Vielen Dank für die Beschreibung des Updates der config.xml. Ich stimme zu, dass solche Änderungen natürlich gefährlich sind - falls falsch umgesetzt.
Eine letzte Frage zur Aussage:
Gibt es hierfür eine Begründung?
Eine letzte Frage zur Aussage:
Die Firewall-Regel ist technisch und richtlinienmäßig schon besser.
Gibt es hierfür eine Begründung?
Zitat von @Frontier:
Gibt es hierfür eine Begründung?
Naja, falls das Interface aus welchen Gründen auch immer trotzdem wieder hoch kommt, kommen die User ohne Firewall-Regel trotzdem noch in den Tunnel.Die Firewall-Regel ist technisch und richtlinienmäßig schon besser.
Gibt es hierfür eine Begründung?
Zitat von @Frontier:
Gibt es hierfür eine Begründung?
Die Firewall-Regel ist technisch und richtlinienmäßig schon besser.
Gibt es hierfür eine Begründung?
Ich kenne das genaue Handling von Wireguard auf pfSense und dieses Vorgehens nicht, aber es stellen sich einige Fragen, denen man mit der Firewall-Regel aus dem Weg geht:
"Richtlinienmäßig": Ein Port/Protokoll ist als offen zu betrachten, wenn er vom Firewall-Regelwerk zugelassen wird. Du willst den Wireguard-Dienst temporär zumindes funktionslos machen. Während er funktionslos ist, ist das Offenlassen des Port aber unnötig; Ports sollen nicht unnötig offen sein. Umgekehrt hingegen erfüllt schon das Schließen des Ports den Zweck der Funktionslosigkeit.
Ja, ein in der Firewall offener Port, auf dem nichts lauscht, ist technisch unschädlich. Aber auch nicht für Audits o.ä. vorzeigbar. Was wiederum technisch eine Rechtfertigung darin hat, dass dieses Vorgehen fragil ist: Ist der WG-Dienst denn auch beendet, wenn man das Interface deaktiviert, oder eben nur funktionslos? Wenn die pfSense crasht/neustartet, ist dann der Dienst auf dem Port aktiv, ist evtl. das Interface wieder aktiv?
Bzgl. der Bearbeitung der Konfiguration sieht die Dokumentation eigentlich einen dritten Schritt vor: "Reboot, or use the GUI to save/reload whichever part of the firewall utilizes the edited settings"
Selbst wenn "rm /tmp/config.cache" für die Synchronisation des Interface-Zustandes ausreicht, ist ja die Frage, was z.B. mit den Firewall-Regeln auf dem reaktivierten Interface ist, ob die nicht neu geladen werden müssen.
Während er funktionslos ist, ist das Offenlassen des Port aber unnötig; Ports sollen nicht unnötig offen sein. Umgekehrt hingegen erfüllt schon das Schließen des Ports den Zweck der Funktionslosigkeit.
Das macht natürlich Sinn.
Naja, falls das Interface aus welchen Gründen auch immer trotzdem wieder hoch kommt, kommen die User ohne Firewall-Regel trotzdem noch in den Tunnel.
Dem kann ich nur begrenzt folgen: Wenn aus irgendeinem Grund die Firewall-Regel versagt, hat man dasselbe Problem. Vermutlich ist ein wenig Redundanz daher gar nicht verkehrt. Dann könnte man die obige Single-Point-of-Failure-Problematik lösen. Wird das im professionellen Bereich gemacht?
PS: Versprochen: das war meine letzte Frage : - )
BTW
... was mir an der Umsetzung mit dem Wireguard-Port nicht gefällt, ist dass aktive Sitzungen nicht gestoppt werden. Das ist beim Deaktivieren des Interfaces nicht der Fall.
... was mir an der Umsetzung mit dem Wireguard-Port nicht gefällt, ist dass aktive Sitzungen nicht gestoppt werden. Das ist beim Deaktivieren des Interfaces nicht der Fall.
Die Annahme, dass die Firewall-Regel eher nicht versagt, ist dadurch begründet, dass sie in der Konfigurationsverwaltung und -Steuerung der pfSense angelegt ist, und alle Abhängigkeiten in diesem Software-Projekt gepflegt werden. Dadurch nimmt es einem ja generell viel Arbeit im Umgang mit dem Grundsystem und den Paketen ab, die bei jedem Basteln unter der Haube möglichst vollständig durchdacht und nachgebildet werden muss. In der Regel fallen dabei Aspekte unter den Tisch, wie z.B. Persistenz über Fehlerzustände und Neustarts hinweg, an die man einfach nicht denkt, sie nicht ausreichend löst, oder die auch nach einigen Updates überraschen können. Das ist einfach der Weg des geringsten Widerstandes, den man in einer gegebenen Implementierung wie der pfSense sucht.
Ok, das ist ein guter Einwand, für die ursprünglich vorgeschlagene Regel, aber lösbar: Wenn du eine vorrangige, zustandslose (State Type: none in den erweiterten Einstellungen) Blockierregel einsetzt, sollte das nicht auftreten.
Zitat von @Frontier:
BTW
... was mir an der Umsetzung mit dem Wireguard-Port nicht gefällt, ist dass aktive Sitzungen nicht gestoppt werden. Das ist beim Deaktivieren des Interfaces nicht der Fall.
BTW
... was mir an der Umsetzung mit dem Wireguard-Port nicht gefällt, ist dass aktive Sitzungen nicht gestoppt werden. Das ist beim Deaktivieren des Interfaces nicht der Fall.
Ok, das ist ein guter Einwand, für die ursprünglich vorgeschlagene Regel, aber lösbar: Wenn du eine vorrangige, zustandslose (State Type: none in den erweiterten Einstellungen) Blockierregel einsetzt, sollte das nicht auftreten.
@ C.R.S: Vielen Dank. Auch wenn ich eigentlich keine Frage mehr stellen wollte:
Wie sollte eine solche Blockierregel aussehen? Die Reihenfolge der Regeln sowie den State-Type anzupassen bekomme ich natürlich hin.
Wie sollte eine solche Blockierregel aussehen? Die Reihenfolge der Regeln sowie den State-Type anzupassen bekomme ich natürlich hin.
Einfach ein Blockieren von UDP auf dem Port oder Custom-Port von Wireguard mit Zeitplan, sodass diese Regel aktiv ist, wenn die Zulassen-Regel inaktiv ist/wäre (die braucht dann an sich keinen eigenen Zeitplan, kann man aber natürlich trotzdem noch steuern, damit zumindest neue Sessions auch bei versehentlich umsortierten Regeln noch kontrolliert werden).
@ C.R.S. Vielen Dank für die Antwort. Leider wird eine bestehende Verbindung noch immer nicht unterbrochen - selbst wenn ich sowohl eine Pass-Regel und eine Bock-Regel und beide mit NONE ausführe bzw. deaktiviere.
Zitat von @Frontier:
@ C.R.S. Vielen Dank für die Antwort. Leider wird eine bestehende Verbindung noch immer nicht unterbrochen - selbst wenn ich sowohl eine Pass-Regel und eine Bock-Regel und beide mit NONE ausführe bzw. deaktiviere.
@ C.R.S. Vielen Dank für die Antwort. Leider wird eine bestehende Verbindung noch immer nicht unterbrochen - selbst wenn ich sowohl eine Pass-Regel und eine Bock-Regel und beide mit NONE ausführe bzw. deaktiviere.
Muss ich in den nächsten Tagen ausprobieren, ich habe gerade keinen Zugang zu einer pfSense. Kann sein, dass die Logik mit der Blockierregel falsch ist, wenn die implizite Zustands-Regel als erste matcht. Aber prinzipiell müsste man die Verbindung auch stateless erlauben können, bzw. du hast das wohl schon versucht. Dann sollte sie nicht gehalten werden können.
Ich muss einräumen, dass das auf der pfSense nicht so funktioniert, wie ich es umgesetzt hätte: Wird die Block-Regel durch Zeitplan aktiv, wird zwar der State-Counter der nachfolgenden Pass-Regel im GUI zurückgesetzt, die States bleiben aber aktiv.
Den Zugang zustandslos zu konfigurieren, ist auch keine Option. Die Antwort-Regel unter den Floating-Rules, die ich dafür versucht habe, funktioniert nicht nur nicht, sondern sammelt auch States an. Wahrscheinlich müsste man die ganze Instanz auf Stateless-Inspection umstellen (falls das geht), um das durch Konfiguration sauber zu kontrollieren.
Eine Improvisation, die praktisch vielleicht ausreicht, wäre, den State-Timeout in der Zugangs-Regel herabzusetzen. Ich glaube, das ist standardmäßig so in der Größenordung 30s. Das Minimum von 1s würde die Wahrscheinlichkeit einer Unterbrechung surch den Zeitplan erhöhen, je nach Traffic. Natürlich keine Garantie und nicht viel schöner als das mit dem Interface, gebe ich zu.
Den Zugang zustandslos zu konfigurieren, ist auch keine Option. Die Antwort-Regel unter den Floating-Rules, die ich dafür versucht habe, funktioniert nicht nur nicht, sondern sammelt auch States an. Wahrscheinlich müsste man die ganze Instanz auf Stateless-Inspection umstellen (falls das geht), um das durch Konfiguration sauber zu kontrollieren.
Eine Improvisation, die praktisch vielleicht ausreicht, wäre, den State-Timeout in der Zugangs-Regel herabzusetzen. Ich glaube, das ist standardmäßig so in der Größenordung 30s. Das Minimum von 1s würde die Wahrscheinlichkeit einer Unterbrechung surch den Zeitplan erhöhen, je nach Traffic. Natürlich keine Garantie und nicht viel schöner als das mit dem Interface, gebe ich zu.
