Multimanagement vieler pfSensen
-
Hallo Gemeinde,
ich möchte fragen ob es eine Lösung/Option gibt/geplant ist, viele gleich konfigurierte pfSensen zentral zu managen.
Ich denke da natürlich vorzugsweise an das LAN Interface oder aber auch an Snort und andere Packete welche zur absicheruung sinvoll sind, ebenso wie ein Squid.
Mir ist klar das ich da etwas träume, aber eventuell wurde solch ein/oder änlicher Wunsch, bereits schoneinmal geäussert.Eventuell gibt es ja auch andere möglichkeiten soetwas zu lösen.
Das Dilema ist wie immer Zeit die man einfach nicht bekommt ;)
Ansonsten ist und bleibt die pfSense ein cooles Projekt.
-
Meinst Du ein Tool, welches alle Sensen gleichzeitig konfiguriert bzw. Änderungen sofort auf alle pfSense anwendet?
Oder Überwachungsmöglichkeiten wie Zabbix, Nagios, Icinga usw..? -
Hallo mike69,
DANKE für deine Rückfrage.
JAP gleichzeitig konfiguriert, wäre das was ich erfragen wollte.
Mir ist klar das es da viel gibt wo man aufpassen muss, aber dafür kann man ja ALIAS Regeln und VLAN nutzen.Würde es da eine Möglichkeit geben, dann würde ich da auch das Konzeptionell nochmal entsprechend überdenken.
Monitoring ist aktuell ein Traum, was nicht an mir liegt, sondern an den Chefs welche einfach einen beschränkten Horizont haben und wollen das du eben "relativ gesehen", wichtigers zu tun hast.
Zentralles Logging würde da für mich auch dazu gehören wie Syslog und Kiwi oder Calamaris etc.
Ich habe ca 30 pfSensen zu verwalten, was man auch nicht mal gerade eben so macht. -
Boah, wüsste ich auch nicht auf Anhieb.
Wenn es ein Tool geben würde, müsstest Du ja min. 29 VPN-Verbindungen zu den Sensen gleichzeitig aufrecht halten.Nutze pfSense nur privat. Eventuell gibt eine Möglichkeit, mal sehen was noch kommt an Antworten.
-
Hallo mike29,
JEP kein leichtes Therma ;)
Ich habe die pfSense bereits auch seit jahren Privat im Einsatz was ich einen Moderator hier zu verdanke ;) .
Grüße an Jens :)Zudem habe ich bei den besagten sensen bereits einen VPN Rückkanal am laufen. Ich wollte primär nur sehen welche IP meine Gegenstelle hat, falls die sich wieder ändert. Sie bauen alle brav wieder die Verbindung auf, und ich muss dann nur die IP in der Client Konfig anpassen für einen Remotezugriff.
Das Zielnetz gibt es auch gar nicht um weiteren Ärger zu vermeiden nur der Tunnel ist wichtig um die IP der Gegenstelle zu sehen.
Das Zielnetz hätte auch auf einer extra Schnittstelle liegen können, oder ein VLAN um dort sinnvolle Infrastruktur zu betreiben (Auswertung und Services für AUssenstellen). Doch da ich keine Mittel habe um das Sinnvoll weiter zu spinnen gegnügt, zu wissen welche Aussenstelle welche IP hat um diese sensen dann zu konfigurieren.
Wünschen würde ich mir Monitoring und vor allem zentrales Logging um Zentral sehen zu können wenn es irgendwo sicherheitstechnisch Probleme mir einem Client gibt, doch dafür fehlen hier die Mittel und das Verständnis.Ich sparre mir telefoniererei und fahrerei.
Somit betreibe ich ein wenig Arbeitserleichterung ;) -
@megazocker said in Multimanagement vieler pfSensen:
Ich wollte primär nur sehen welche IP meine Gegenstelle hat, falls die sich wieder ändert. Sie bauen alle brav wieder die Verbindung auf, und ich muss dann nur die IP in der Client Konfig anpassen für einen Remotezugriff.
Moin.
Wäre es nicht einfacher, das für jede Sense mit dyn. DNS zu managen?
Mal so als Laie, eine Firma mit 29 Aussenstellen wird sich sicher eine eigene Domain leisten können, wo sich 30 Subdomains einrichten lassen. Meine für 10 Taler/Jahr kann schon 10 Subdomains.
Mike
-
@mike69
Nein, geht am Thema vorbei ;)Alla spdns dyndns oder URL auf Statische IPS (das sie auch nicht sind) ist definitiv unerwünscht.
Zuhause, keine Frage, mach ich das schon seit jahren so.Da wo ich arbeite ist Sicherheit ein schweres Thema ... in jeder Hinsicht.
-
Da ist wohl leider nichts in der Pipeline: https://forum.netgate.com/topic/140623/management-pfsense-from-centralized-location
-Rico
-
Hmm schade, aber ein Versuch wars wert.
DANKE aber, ich kann mir vorstellen das es auch für andere interessant gewesen wäre.
-
Das ist ein relativ alter Thread. Das Problem war, dass die API als Grundlage für 2.5 geplant war, da 2.5 aber ein Re-Basing auf FreeBSD 12.x inne hat und dieses momentan noch etwas holprig läuft. Mit dem Rebasing auf 12.x haben aber mehr als nur pfSense zu kämpfen. Da das insgesamt mehr Zeit frisst als geplant war, hat man die API nach hinten verschoben, damit man nicht 2 Großbaustellen auf einmal aufmacht. Sobald die API mit reinkommt - und geplant ist das schon, da Erfahrung mit Restconf ja jetzt durch TNSR da ist - ist auch der nächste Step (UI von lokaler Maschine wegziehen, PHP loswerden, etc.) dann keine zu lange Strecke mehr entfernt.
Gruß
-
Hy JeGr,
dann dank ich dir mal für deine Info, und warte ich mal brav ab, wie sich das weiterentwickelt.Best Grüße aus der Versenkung ;)
