9
Design-Frage OPNsense HA-Cluster mit VLAN-Routing
Hallo,
im Zuge einer Maßnahme zur Homogenität der Netzwerke an verschiedenen Standorten, bin ich gerade dabei mir Gedanken über das Design als eine Art Blaupause zu machen. An manchen Standorten gibt es noch keine VLANs, aber an manchen schon.
Bisher war es so gewesen das meist nur eine pfSense/OPNsense als VLAN-Router für alle VLANs zuständig war. Er hatte in jedem VLAN und Subnetz brav ein Beinchen stehen, hat DHCP für alle Netze gemacht. Nun ist der Bedarf nach Ausfallsicherheit formuliert worden, das kann man ja wunderbar bei den Sensen mit CARP regeln. Solange es ein flaches Subnetz ist, sehe ich da keine Probleme.
Aber bei vielen Netzen, bedeudet das, das man gezwungen ist immer in jedem Netz drei Adressen zu definieren: jeweils 2 Adressen für die "physischen Interfaces" der Sensen und eine Virtual IP die dann von den Clients als Gateway verwendet wird. Bei nur maximal 30 VLANs ist das eine Menge Pflegeaufwand und sehr viele Adressen die man belegt für diesen Luxus.
Meine Idee als Beispiel mal:
3 VLANs
Server VLAN10 10.10.0.0/24
Clients VLAN20 10.11.0.0/24
Drucker VLAN30 10.12.0.0/24
VLAN20 und VLAN30 über Layer3-Switch (Brocade ICX Stack mit Hitless Failover) routen. VLAN10 mit den Servern zu einem Transfernetz machen und nur dort die drei Adressen für HA-Cluster der Sensen konfigurieren.
Der Layer3-Switch hätte dann die Adressen: 10.10.0.254, 10.11.0.254, 10.12.0.254
Das HA-Cluster: Sense1 10.10.0.100, Sense2 10.10.0.101, CARP VIP 10.10.0.1
Vorteil: Es werden nur drei Adressen belegt, interner Routing-Traffic belastet nicht die Sensen, klare Struktur, der Layer3-Switch bräuchte weiterhin nur eine Adresse in jedem Netz da Stack.
Nachteil: Interne ACLs zwischen den VLANs müssen am Layer3 gemacht werden, man muss DHCP-Relay arbeiten wenn man die Sense weiterhin als DHCP-Server haben möchte.
Was haltet ihr davon? Kann man das so machen oder lieber den Weg über die Sense komplett als VLAN-Router machen?
Grüße
im Zuge einer Maßnahme zur Homogenität der Netzwerke an verschiedenen Standorten, bin ich gerade dabei mir Gedanken über das Design als eine Art Blaupause zu machen. An manchen Standorten gibt es noch keine VLANs, aber an manchen schon.
Bisher war es so gewesen das meist nur eine pfSense/OPNsense als VLAN-Router für alle VLANs zuständig war. Er hatte in jedem VLAN und Subnetz brav ein Beinchen stehen, hat DHCP für alle Netze gemacht. Nun ist der Bedarf nach Ausfallsicherheit formuliert worden, das kann man ja wunderbar bei den Sensen mit CARP regeln. Solange es ein flaches Subnetz ist, sehe ich da keine Probleme.
Aber bei vielen Netzen, bedeudet das, das man gezwungen ist immer in jedem Netz drei Adressen zu definieren: jeweils 2 Adressen für die "physischen Interfaces" der Sensen und eine Virtual IP die dann von den Clients als Gateway verwendet wird. Bei nur maximal 30 VLANs ist das eine Menge Pflegeaufwand und sehr viele Adressen die man belegt für diesen Luxus.
Meine Idee als Beispiel mal:
3 VLANs
Server VLAN10 10.10.0.0/24
Clients VLAN20 10.11.0.0/24
Drucker VLAN30 10.12.0.0/24
VLAN20 und VLAN30 über Layer3-Switch (Brocade ICX Stack mit Hitless Failover) routen. VLAN10 mit den Servern zu einem Transfernetz machen und nur dort die drei Adressen für HA-Cluster der Sensen konfigurieren.
Der Layer3-Switch hätte dann die Adressen: 10.10.0.254, 10.11.0.254, 10.12.0.254
Das HA-Cluster: Sense1 10.10.0.100, Sense2 10.10.0.101, CARP VIP 10.10.0.1
Vorteil: Es werden nur drei Adressen belegt, interner Routing-Traffic belastet nicht die Sensen, klare Struktur, der Layer3-Switch bräuchte weiterhin nur eine Adresse in jedem Netz da Stack.
Nachteil: Interne ACLs zwischen den VLANs müssen am Layer3 gemacht werden, man muss DHCP-Relay arbeiten wenn man die Sense weiterhin als DHCP-Server haben möchte.
Was haltet ihr davon? Kann man das so machen oder lieber den Weg über die Sense komplett als VLAN-Router machen?
Grüße
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: 7299922275
Url: https://administrator.de/contentid/7299922275
Ausgedruckt am: 24.11.2024 um 16:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
ist machtbar und Praktikabel.
Würde die FW sogar in ein komplett eigenes Transfernetz legen. Das macht die ACL einfacher wenn z.B. ein Netz auf alle Server darf aber nicht ins Internet oder andere Routen außerhalb des Standortes.
IP Design mache ich mittlerweile so:
XX = Standort
YY = VLAN
ZZ = Clients
10.XX.YY.ZZ
Mit einer 10.XX.0.0 / 16 Route hat man dann bei VPN einen ganzen Standort abgedeckt und VLAN sind immer gleich.
Außer man macht NAT über die VPN Route dann ist es natürlich nicht so wild
Gruß
ist machtbar und Praktikabel.
Würde die FW sogar in ein komplett eigenes Transfernetz legen. Das macht die ACL einfacher wenn z.B. ein Netz auf alle Server darf aber nicht ins Internet oder andere Routen außerhalb des Standortes.
IP Design mache ich mittlerweile so:
XX = Standort
YY = VLAN
ZZ = Clients
10.XX.YY.ZZ
Mit einer 10.XX.0.0 / 16 Route hat man dann bei VPN einen ganzen Standort abgedeckt und VLAN sind immer gleich.
Außer man macht NAT über die VPN Route dann ist es natürlich nicht so wild
Gruß
2
Dein Weg des hybriden Routing über L3 Switch und Firewall ist gängige Praxis, per se also richtig.
Man routet nur die wirklich sicherheitsrelevanten IP Netze über die Firewall bzw. führt diese nur als reine L2 Netze über die Switch Infrastruktur und alle anderen Netze routet man zentral über den Switch Stack.
Du beschreibst also letztlich ein übliches und gängiges Standard Desing in deinem Umfeld.
Man routet nur die wirklich sicherheitsrelevanten IP Netze über die Firewall bzw. führt diese nur als reine L2 Netze über die Switch Infrastruktur und alle anderen Netze routet man zentral über den Switch Stack.
Du beschreibst also letztlich ein übliches und gängiges Standard Desing in deinem Umfeld.
Bisher gibt es nur ein Problem bei der ganzen Sache: DHCP weder von der pfSense noch von OPNsense (denke mal beides isc) unterstützt Multi Scope.
Somit bringt mir das mit dem IP Helper oder DHCP Relay recht wenig. Würde bedeuten ich müsste einen extra DHCP+DNS aufsetzen.
Somit bringt mir das mit dem IP Helper oder DHCP Relay recht wenig. Würde bedeuten ich müsste einen extra DHCP+DNS aufsetzen.
Hi,
bei einem HA-Cluster wandern DHCP+DNS im Fehlerfalle doch auf der OPNsense mit und somit "behält" dieser auch seine CARP-IP. Oder wo ist da Dein Problem?
cu,
ipzipzap
bei einem HA-Cluster wandern DHCP+DNS im Fehlerfalle doch auf der OPNsense mit und somit "behält" dieser auch seine CARP-IP. Oder wo ist da Dein Problem?
cu,
ipzipzap
Zitat von @ipzipzap:
Hi,
bei einem HA-Cluster wandern DHCP+DNS im Fehlerfalle doch auf der OPNsense mit und somit "behält" dieser auch seine CARP-IP. Oder wo ist da Dein Problem?
cu,
ipzipzap
Hi,
bei einem HA-Cluster wandern DHCP+DNS im Fehlerfalle doch auf der OPNsense mit und somit "behält" dieser auch seine CARP-IP. Oder wo ist da Dein Problem?
cu,
ipzipzap
Damit ich beim beschriebenen Setup überhaupt den eingebauten DHCP verwenden kann, muss ich für jedes VLAN einen IP Helper oder anders gesagt DHCP Relay konfigurieren, damit die Clients aus dem entsprechenden Segment ihren Request an die Sense schicken.
Das Problem ist, weder bei pfSense noch bei OPNsense, ist es möglich pro Schnittstelle auf einen DHCP mehr als ein Subnetz zu betreiben. Du kannst bei statischen Leases immer nur innerhalb des Subnetzes des Interfaces Adressen vergeben, sonst wird eine Fehlermeldung ausgeworfen. Zumindest nicht über die GUI. Man müsste die Config auf der CLI händisch entsprechend verbiegen.
Alternativ müsste man der SEnse in jedes VLAN wieder ein Interface packen, aber dann kann ich auch gleich drüber Routen, was ja nicht das Ziel ist. Stattdessen werde ich mir wohl einen kleinen DHCP-Server installieren und die Scopes da definieren, danach den IP Helper auf dessen IP zeigen lassen.
Wenn es das denn nun war, bitte deinen Thread hier dann auch als erledigt schliessen!!
@Fenris14
Kannst du uns sagen, wie Du das jetzt final umgesetzt hast bzw. welchen Multiscope-fähigen DHCP-Server Du jetzt benutzt?
Wir stehen bei uns nämlich jetzt gerade genau vor demselben Problem und überlegen, wo und wie wir DHCP umsetzen bei 20-30 VLANs. Über die OPNsense aus genannten Gründen definitv nicht.
cu,
ipzipzap
Kannst du uns sagen, wie Du das jetzt final umgesetzt hast bzw. welchen Multiscope-fähigen DHCP-Server Du jetzt benutzt?
Wir stehen bei uns nämlich jetzt gerade genau vor demselben Problem und überlegen, wo und wie wir DHCP umsetzen bei 20-30 VLANs. Über die OPNsense aus genannten Gründen definitv nicht.
cu,
ipzipzap
Im Endeffekt bin ich beim Klassiker gelandet: isc-dhcp-server.
Beitreibe diesen mit einem Power DNS (pdns). Weil der Schneller und einfacher zu handhaben war als der Bind. Aber im Endeffekt würde ich mittlerweile auch nicht mehr den ISC nehmen sondern mir an deiner Stelle mal den Kea DHCP anschauen.
Danach habe ich mit dem IP Helper Feature unserer Core-Switche die Anfragen weitergeleitet. Beim DNS bin ich auch mehrstufig unterwegs. Im Endeffekt verwende ich nach wie vor von der OPNsense den Unbound als Forwarder. Der hat ein Forwarding für die interne Zone zum pdns mit dem DHCP. Die Clients bekommen dann vom DHCP auch den Forwarder als Primary DNS eingetragen.
Beitreibe diesen mit einem Power DNS (pdns). Weil der Schneller und einfacher zu handhaben war als der Bind. Aber im Endeffekt würde ich mittlerweile auch nicht mehr den ISC nehmen sondern mir an deiner Stelle mal den Kea DHCP anschauen.
Danach habe ich mit dem IP Helper Feature unserer Core-Switche die Anfragen weitergeleitet. Beim DNS bin ich auch mehrstufig unterwegs. Im Endeffekt verwende ich nach wie vor von der OPNsense den Unbound als Forwarder. Der hat ein Forwarding für die interne Zone zum pdns mit dem DHCP. Die Clients bekommen dann vom DHCP auch den Forwarder als Primary DNS eingetragen.
1
Danke für die Rückmeldung. Kea als Nachfolger vom ISC ist hier auch gerade in der näheren Auswahl.
