*Inhalt gelöscht*
Zuletzt bearbeitet von einem Moderator:
[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)
besterino
Legende
Es gibt so ein paar Dinge, die für mich einfach nur laufen sollen, möglichst wenig und wenn nur idiotensicheres Handanlegen erfordern und mit denen man generell nicht herumspielt. 
Dazu gehören für mich Routing, Firewall und VPN-Zugang. VPN hab ich darum in dedizierter Hardware. Firewall/Routing aktuell erstmal als VM (zum Lernen, vor allem was ich langfristig wirklich will), optional später evtl. auch mal in dedizierter Hardware.
Aus Neugier: welches Killerfeature hat den Opnsense, das die pfsense nicht hat?
Dazu gehören für mich Routing, Firewall und VPN-Zugang. VPN hab ich darum in dedizierter Hardware. Firewall/Routing aktuell erstmal als VM (zum Lernen, vor allem was ich langfristig wirklich will), optional später evtl. auch mal in dedizierter Hardware.Aus Neugier: welches Killerfeature hat den Opnsense, das die pfsense nicht hat?
Weltherrscher
Enthusiast
- Mitglied seit
- 28.04.2008
- Beiträge
- 1.122
Nein, aber du ja auch nicht.
Die Sense ist hier Mittel zum Zwecke, die Dienste nach außen einigermaßen sicher und komfortabel freizugeben.
Auf der Sense selbst laufen Wireguard, Adguard, Unbound für lokale DNS-Auflösung, HAProxy als reverse Proxy und natürlich IDS und die Firewall selbst.
Nebenher routet sie zwischen den VLANs den nötigen Verkehr.
Luckysh0t
Enthusiast
Ich denke, man kann das eher in Philosophien einordnen, OPNSense ist schneller und moderner bei Funktionen, und pfsense eher konservativ. Ubuntu vs Debian, quasi ^^ Zumindest ist dass mein Eindruck.
besterino
Legende
Nachdem ich heute fast den ganzen Tag mit dem (nur teilweise erfolgreichen) Versuch verbracht habe, einen pfsense HA-cluster einzurichten, vielleicht habt Ihr ja eine Idee:
Ich versuche, HA zwischen einer Hyper-V VM und einer physischen Kiste einzurichten. Da die physische Kiste nur 2 NICs hat, habe ich als SYNC-Interface ein eigenes VLAN mit der ID 1000 eingerichtet. Entsprechend das VLAN auch auf dem physischen Switch und in der VM hinzugefügt (der hab ich dann auch keine weitere vNIC mehr hinzugefügt). Die VM soll Master/Primary sein (hat mehr Bumms), die physische Kiste Secondary.
Das klappte auch grundsätzlich soweit, dass sich die beiden pfSensen finden und alle Einstellungen vom Primary auf den Secondary gesynced wurden. Grundsätzlich Connectivität ist also gegeben.
Allerdings behaupten BEIDE pfSensen unter "Status --> CARP (failover)", dass sie der MASTER wären. Die Secondary müsste eigentlich BACKUP zeigen... Für die DHCP-Server ganz unten "Status --> DHCP Leases" funktioniert es witzigerweise, da ist einer Primary und der andere Secondary (wie es sein soll). Sobald ich aber über DHCP als Default-GW und DNS nicht mehr die IP (x.x.x.1) der Primary-pfSense sondern der virtuellen IP (x.x.x.254) an Clients verteile, kommen die dann auch leider nicht mehr ins Internet. Komischerweise funktioniert auch kein Ping mehr aus dem eigenen Subnetz raus, was vorher ging.
Ich vermute klassisches "Split-Brain"? Außerdem hab ich bisher die Firewall-Regeln ja anhand nur einer einzigen pfSense gebastelt - muss ich die nun alle anpacken und von "ADDRESS" z.B. auf "x.x.x.254" umbiegen, wo es um Regeln der pfSense selbst geht (Zugriff auf DNS, Web-GUI usw.) damit die auch im Falle eines Failovers weiter funktionieren? Aber wie erkläre ich der pfSense, dass die Dienste dann auch auf der vIP horchen und nicht (nur) auf den "echten" pfSense-IPs?
Wie finde ich heraus, wo es genau klemmt? Kommt so vieles in Betracht, evtl. macht mir ja schon der Hyper-V vSwitch einen Strich durch die Rechnung (irgendwo stand was, man solle v-Switches in den promiscuous mode setzen)? Muss ich auch auf dem physischen Switch irgendwas über das VLAN-tagging beachten (das funzt ja anscheinend, sonst würden die sich schon nicht syncen)?
Ich versuche, HA zwischen einer Hyper-V VM und einer physischen Kiste einzurichten. Da die physische Kiste nur 2 NICs hat, habe ich als SYNC-Interface ein eigenes VLAN mit der ID 1000 eingerichtet. Entsprechend das VLAN auch auf dem physischen Switch und in der VM hinzugefügt (der hab ich dann auch keine weitere vNIC mehr hinzugefügt). Die VM soll Master/Primary sein (hat mehr Bumms), die physische Kiste Secondary.
Das klappte auch grundsätzlich soweit, dass sich die beiden pfSensen finden und alle Einstellungen vom Primary auf den Secondary gesynced wurden. Grundsätzlich Connectivität ist also gegeben.
Allerdings behaupten BEIDE pfSensen unter "Status --> CARP (failover)", dass sie der MASTER wären. Die Secondary müsste eigentlich BACKUP zeigen... Für die DHCP-Server ganz unten "Status --> DHCP Leases" funktioniert es witzigerweise, da ist einer Primary und der andere Secondary (wie es sein soll). Sobald ich aber über DHCP als Default-GW und DNS nicht mehr die IP (x.x.x.1) der Primary-pfSense sondern der virtuellen IP (x.x.x.254) an Clients verteile, kommen die dann auch leider nicht mehr ins Internet. Komischerweise funktioniert auch kein Ping mehr aus dem eigenen Subnetz raus, was vorher ging.
Ich vermute klassisches "Split-Brain"? Außerdem hab ich bisher die Firewall-Regeln ja anhand nur einer einzigen pfSense gebastelt - muss ich die nun alle anpacken und von "ADDRESS" z.B. auf "x.x.x.254" umbiegen, wo es um Regeln der pfSense selbst geht (Zugriff auf DNS, Web-GUI usw.) damit die auch im Falle eines Failovers weiter funktionieren? Aber wie erkläre ich der pfSense, dass die Dienste dann auch auf der vIP horchen und nicht (nur) auf den "echten" pfSense-IPs?
Wie finde ich heraus, wo es genau klemmt? Kommt so vieles in Betracht, evtl. macht mir ja schon der Hyper-V vSwitch einen Strich durch die Rechnung (irgendwo stand was, man solle v-Switches in den promiscuous mode setzen)? Muss ich auch auf dem physischen Switch irgendwas über das VLAN-tagging beachten (das funzt ja anscheinend, sonst würden die sich schon nicht syncen)?
@besterino Wozu HA. Das macht alles nur sehr kompliziert und steht meiner Meinung nach in keinem Verhältnis zum möglichen Gewinn, im Gegenteil. Und wenn Du virtualisierst, solltest Du eh immer ein Backup zurückspielen können. Ich mache um HA einen großen Bogen. Ich hab aber eh eine Fritzbox, die in vorderster Front ihren Dienst tut, zur Not auch alleine. Meinung Ende und letzter Kommentar zum Thema von mir.
Zuletzt bearbeitet:
Hab die Tage mal nach und nach alle *Sensen unter meiner Gewalt geupdated.
Migration auf den neuen DHCP steht noch aus bei meiner Moehre. Rest lief soweit erstmal Fehlerfrei und funktioniert auch scheinbar noch alles.
Was ein wenig doof war: Beim Update von 2 Remote-Standorten blieb der automatische Reboot aus bzw. das VPN kam nachm Update nichtmehr selbststaendig hoch. Musste haendisch nachgeholfen werden.
Migration auf den neuen DHCP steht noch aus bei meiner Moehre. Rest lief soweit erstmal Fehlerfrei und funktioniert auch scheinbar noch alles.
Was ein wenig doof war: Beim Update von 2 Remote-Standorten blieb der automatische Reboot aus bzw. das VPN kam nachm Update nichtmehr selbststaendig hoch. Musste haendisch nachgeholfen werden.
@p4n0 die Migration auf das "neue" DHCP hat auf meiner Sense vor Kurzem problemlos geklappt.
Hat schon jemand Erfahrungen mit der Migration der "alten" Firewall-Rules auf die "neuen" Rules gemacht?
Ich zögere mit der Umstellung, weil sowas immer ein hohes Gefahrenpotential mitbringt, dass am Ende irgendwas klemmt 😅
Hat schon jemand Erfahrungen mit der Migration der "alten" Firewall-Rules auf die "neuen" Rules gemacht?
Ich zögere mit der Umstellung, weil sowas immer ein hohes Gefahrenpotential mitbringt, dass am Ende irgendwas klemmt 😅
Steht bei mir auch noch aus. Zumindest fuehlt sich die 'neue' Version noch so an als wuerde sie korrekt (mit den alten rules) arbeiten. Wer das ab Donnerstag alles nachholen.
Dinge wie ACME, Dyndns, HAProxy (Reverse) mit SSL Offloading etc funktioniert alles wie gewohnt.
Ja ich hab den Assi benutzt, exportiert -> importiert, hat alles funktioniert.
Meine Regeln waren wohl nicht komplex genug um dabei was kaputt gehen zu lassen
Danke für euer Feedback. Habe jetzt auch keine superkomplexen Regeln, allerdings heute alles "Floating", was dann portiert werden muss. Werde mir das mal ansehen.
Alles Floating zu machen war ja nie empfehlenswert. Von daher vielleicht ganz gut, dass die OPNsense-Userbase da mal geerdet wird.
Ich seh den Task auch als gute Gelegenheit an alles sauber in Gruppen / Aliase zu packen und nur noch damit in Zukunft zu arbeiten.
Ist aktuell schon recht fragmentiert gewachsen und nichtmehr so einfach zu verstehen.
Grad wenn man mehrere S2S Standorte mit unterschiedlichen Netzen hat sollte man sich im Vorfeld ein valides Konzept ueberlegen wie man das Ruleset aufbaut. Wird nachgeholt
Ist aktuell schon recht fragmentiert gewachsen und nichtmehr so einfach zu verstehen.
Grad wenn man mehrere S2S Standorte mit unterschiedlichen Netzen hat sollte man sich im Vorfeld ein valides Konzept ueberlegen wie man das Ruleset aufbaut. Wird nachgeholt
Ich hab da auch Nachholbedarf, wie ihr schon festgestellt habt. Bin bislang mit den Floating-Rules allerdings sehr gut gefahren muss ich sagen, keine Probleme für mein überschaubares Heimnetz mit ein bisschen VPN und ner handvoll Tunneln.
Ähnliche Themen
