OPNsense incoming

@blurrrr Ich habe mich fast todgesucht, aber es scheint keine USB-Netzadapter mit Intel-Chips zu geben. Ich habe eigentlich nur Asix und Realtek gefunden.
 
CARP habe ich im Moment nur für wichtigen VLANs eingerichtet, sowohl für die jeweilige private IPv4 als auch für eine IPv6-ULA aus dem Subnetz.

carp.png


Was das IPv6 und ULA, GA und LLA angeht, so habe ich hier aktuell ein bisschen Überfluss. Damit bin ich aber wohl auch nicht allein, ich habe schon entsprechende Pull-Requests für OPNsense gefunden, die dieses "Problem" auch adressieren. Spezielle das HA für DHCPv4 ist deutlich besser gelöst als das HA für das DHCPv6.

Das HA für DHCPv6 ist faktisch nicht vorhanden, so dass über das HA-Feature auf der Backup-FW noch einmal ein eigenständiger, zweiter DHCPv6 eingerichtet wird.
Das HA für DHCPv4 ist da besser umgesetz, hier wird die Lease-DB ausgestauscht und die beiden DHCPv4-Server teilen sich den Adresspool.

In meinem konkreten Fall führt es aktuell dazu, dass ein Client im VLAN 4 eine LLA, eine ULA und zwei GA hat (siehe Screenshot). Entsprechend gibt es auch zwei IPv6-Standardgateways im VLAN.

IP.png

Ich muss mal sehen, was ich damit macht bzw. ob es da bald einen Lösungsansatz aus OPNsense gibt.
 
Sind ja ernüchternde Erkenntnisse. Insgeheim hatte ich gehofft das ein Antwort à la "GA geht so und so kommt". Ich würde gerne public traffic auf der CARP-IP aufschlagen lassen (wie immer das gehen soll) und dann vom HA-Proxy nach hinten raus auf ULAs zu verteilen.
 
Confluencer schrieb:
Sind ja ernüchternde Erkenntnisse. Insgeheim hatte ich gehofft das ein Antwort à la "GA geht so und so kommt". Ich würde gerne public traffic auf der CARP-IP aufschlagen lassen (wie immer das gehen soll) und dann vom HA-Proxy nach hinten raus auf ULAs zu verteilen.
Zum Vergrößern anklicken....

Das kannst Du machen, aber das ist "abartig". Wenn DU nur ULA verteilst (da wird es auch keine Dopplung geben) und dann auf der OPNsense ein NAT machst, hast Du das. Aber wie gesagt, dass widerspricht jedem Zweck von IPv6 und warst selbst bei IPv4 nur ein Notnagel und eigentlich nicht gewünscht aus Designsicht.
 
Zuletzt bearbeitet:
Mein erster Reflex ist auch: NAT = pfui.

Ich nutze zuhause mein Fritzbox-LAN als "Kontaminierte-Zone" (alles von den Kids, TV, Tables, Telefone, Konsolen,...). OPNSense Master/Backup haben ihren WAN Port im Fritzbox DMZ-Netz, alles wichtige liegt dahinter. Da ich alles in Container betreiben, ist das mit ipv6 bis zum letzten Meter so eine Sache... Für IPv4 habe ich eine CARP VIP auf den WAN Interfaces von Master und Backup. Für IPv6 hätte ich gerne vergleichbares für die WAN Interfaces. In beiden Fällen geht es ab da mit HA-Proxy weiter. Wenn ich die Wahl zwischen LoadBalancing und NAT habe, dann nehme ich lieber LoadBalancing. Oder ist die Lösung eher Multi-Value DNS mit kurzer TTL, die dann jeweils auf die GA der Ziel-Kisten auflöst?
 
Ich "sehe" hier ein Verständnisproblem von IPv4 und IPv6 First Hop. Vielleicht irre ich mich aber auch.

CARP braucht es im IPv6 eigentlich gar nicht, ich habe es auch nur zum Testen angelegt. Ob ich es nun aktiv habe oder ob ich es wieder lösche, wird keinerlei Änderung an der Funktionalität ergeben.

Für IPv4 ist CARP eine extrem sinnvolle Sache, weil IPv4 blind für den First Hop ist. Es hat einen Grund, warum man für die manuelle Konfiguration eines IPv4-Hosts IP-Adresse, Subnetzmaske und Standard Gateway braucht. Weil ein IPv4 Host sein Standard Gate nicht finden würde, würde man es ihm nicht mitteilen.

Im Design des IPv6 ist man anders an die Sache herangegangen. IPv6 findet den First Hop von selbst.
Beispiel: "Werf mal einen IPv6 Host in ein IPv6 aktives Subnetz. Der Host wird eine Adresse finden und den/die Router im Subnetz ermitteln."
Es gibt einfach keinen Bedarf ihm das zu sagen. Ein IPv4 Host würde erstmal so versauern, er bekäme keine gültige Adresse und wüsste auch nicht, wer Router ist.

CARP, VRRP oder HSRP sind alles "Patches" um dieses Phänomen anzusprechen.

Ich sehe es auch nicht als echtes Problem, dass die Clients zur Zeit eine LLA, eine ULA und zwei GA haben. Es ist in meinen Augen eher ein kosmetisches Phänomen, dass nicht unbedingt sein muss. Aber die GA nutze ich so oder so nur für die Kommunikation "nach außen". Innerhalb meines LAN ist für mich für alle internen Datenverkehre die ULA maßgeblich.

Vom Prinzip her habe ich somit schon direkt eine Traffic-Trennung... die LLA macht die notwendigen Basisfunktionen (Routing, Neighbor Discovery, usw.), die ULA macht den internen (sensitiven) Datenverkehr und die GA macht den Verkehr ins öffentliche Internet.

Jetzt hast Du noch Loadbalancing in den Raum geworfen, das ist auch gut. Aber das hat auch nichts mit CARP oder den anderen Verfahren zu tun. CARP ist kein Loadbalancing, dass ist einfach nur die Sicherstellung der Erreichbarkeit einer Adresse bzw. eines Dienstes unter einer Adresse. CARP ist ein Active-Passive Clusterlösung. Da hast Du in der Praxis sogar noch mehr Loadbalancing, wenn Du mit GAs arbeitest. Jeder der GAs ist eineindeutig einer FW zuzuordnen, weil die eine verteilt Netz A und die andere Netz B. Für den Client sind beide Netze aber erst einmal gleichwertig. Eine zufällige und ungeplante Verteilung der Anfragen auf die beiden GAs und damit in der Folge auf die beiden FW tritt da fast schon von selbst ein.
 
Dritter Zwischenbericht
Es geht weiter, die beiden neuen USB-Netzadapter sind da. Erstmal habe ich nur zwei zum Testen genommen, wenn alles klappt werde ich dann auf vier nachrüsten. ;) An jeden der beiden NUCs habe ich erst einmal einen der neuen USB-Netzwerkadapter angesteckt. Die Adapter wurde sofort erkannt und als ue0 in der GUI der OPNsense angezeigt.
ugen0.2: <Realtek USB 10/100/1G/2.5G LAN> at usbus0, cfg=2 md=HOST spd=SUPER (5.0Gbps) pwr=ON (64mA)

EIn kurzer Stabilitätstest der Adapter zeigte kein "Flattern", wie bei den Asix-Chips.
361 packets transmitted, 361 packets received, 0% packet loss
round-trip min/avg/max = 0.219/0.309/0.829 ms
Der simple PING-Test und ein beobachten des ifconfig sieht deutlich besser aus.

Ich habe im Anschluss zwei VLANs inklusive CARP auf die neuen Adapter umgezogen. Auch hier sieht das Ergebnis deutlich erfreulicher aus. Ich bin also zuversichtlich. :cool:
Das von mir erwähnte IPv6-CARP Experiment habe ich dann auch erst einmal beendet, da es für mich keinen Mehrwert gebracht hat - im Gegensatz zu IPv4-CARP.

Ich werde nun die Adapter erstmal weiter beobachten, bevor ich dann die anderen VLANs anfange so umzuziehen, wie ich die Adapterverteilung vorgesehen hatte.
 
Zuletzt bearbeitet:
Ich muss gestehen, optische Trennung bzw. Reduktion der Themen hätte meinem Post gut getan.

Mir geht es tatsächlich ausschließlich um eingehende Requests aus dem Internet - daher auch CARP auf dem WAN Interface der Instanzen.
ich mach gleich mal einen neuen Thread auf, um Deinen nicht weiter zu hi-jacken.
 
Vierter Zwischenbericht
Im Großen und Ganzen ist der Hauptteil der Installation nun abgeschlossen. Beide Knoten meiner HA-OPNsense laufen und sind funktional.
GeoIP habe ich auch eingerichtet, in einem VLAN habe ich auch das IPv6-CARP reaktiviert, da mir tatsächlich ein Mehrwert eingefallen ist.

Da ich die ULAs statisch von der Fritz!Box route, habe ich mittels CARP eine virtuelle IPv6-LLA erzeugt und diese als Routing-Ziel in der Fritz!Box hinterlegt. Beim IPv4 hatte ich es bereits so eingerichtet. Nun läuft das Routing zwischen Fritz!Box und dem OPNsense-Cluster nun zwar staisch, aber über CARP, so dass die Routen der Fritz!Box stets auf die aktive OPNsense zeigen. Die Fritz!Box routet nun die IPv4-Netze zu 172.22.172.21 und die IPv6-Netze zu fe80::172:22:172:21. Aus Faulheit habe ich die virtuelle LLA nahezu synonym zur IPv4 gehalten, so dass, wenn ich mal einen Datenmitschnitt lese, ich das Interface sofort erkenne.

Einen Echttest hatte mein OPNsense-Cluster gestern auch schon. Aus versehen muss ich das Stromkabel am erstern, aktiven Knoten rausgerupft haben. Bemerkt habe ich es, als ich auf das Dashboard wollte und mein Browser mir einen Ladefehler angezeigt hat. Ich habe dann gesehen, dass der NUC vom ersten Knoten tatsächlich aus (stromlos) war. Die Chance habe ich direkt genutzt und mal alles ausprobiert... und mein, bis dahin, theoretisches Setup hat den Test bestanden.

Es war alles verfügbar. Das Routing aus dem Netz der Fritz!Box in alle Netze hinter den OPNsense (IPv4 und IPv6) hat funktioniert, auch der Zugriff auf mein Remote-Netzwerk über VPN wurde erfolgreich vom zweiten Knoten erledigt.

Selbst die Rückübernahme hat erfolgreich, automatisch funktioniert. Ich habe dem ersten Knoten wieder Strom spendiert und nach dessen Reboot waren alle Funktionen wieder bei ihm, inklusive der Master-Status für alle HA-/CARP-Definitionen. Der zweite Knoten war wieder brav Backup geworden.

Im Prinzip wäre das Thema nun als Erfolg erledigt und abgehakt. Aber ich bin noch jemand, der gerne weiterbeobachtet und optimiert. So muss ich sagen, dass ich mich zur Zeit massiv ärgere über die USB-Netzwerkadapter. Ja, ich habe sie mir selbst ausgesucht und ja, ich habe mit den NUCs gute Erfahrungen, bisher aber eben ohne USB-Netzwerkadapter. Ich möchte daher nicht ausschließen, dass es da in absehbarer Zeit nicht doch noch einmal zu einem Hardware-Wechsel kommen könnte. Ich liebäugle schon mit einer süßen, kleinen Hardware-Box. Kompakt, stromsparend und auch Lüfterlos. Der Vorteil an dieser kleinen Hardware-Box ist 2x 10G Ethernet als SFP+ onboard! Damit wäre das Setup in meinen Augen perfekt... ich würde dann jeden der OPNsense-Cluster-Knoten mittels LAGG anbinden.
 
Sehr nice.
Und wie kommst du sonst, unabhängig von HA mit der Sense zurecht?
Irgendwelche Pros und Cons? @rednag fand einst zB die Zeitsteuerung von FW Rules miserabel (ich nutze sowas nicht).
 
tiermutter schrieb:
Und wie kommst du sonst, unabhängig von HA mit der Sense zurecht?
Irgendwelche Pros und Cons?
Zum Vergrößern anklicken....
Ich lerne mich immer noch in die OPNsense ein. Gerade jetzt kurz, bevor ich diesen Post geschrieben habe, habe ich schon wieder etwas aus der arbeitsweise der OPNsense gelernt. Es gibt so viele Dinge, die man auf verschiedene Arten lösen kann, das man erst herausfinden muss, welche (für einen selbst) die optimale Lösung ist.

Exkurs: CARP für IPv4 & IPv6
Anforderung: Ich habe im VLAN der OPNsense zur Fritz!Box hin zwei CARP-Instanzen aktiv, die 172.22.172.21 (VHID 22) und die fe80::172:22:172:21 (VHID 122). Es sind also grundsätzlich zwei getrennte CARP-Instanzen auf dem gleichen Netzwerkinterface, die eine nur für IPv4 und die andere nur für IPv6. Das bedeutet natürlich auch die doppelte Multicast-Last für CARP in diesem VLAN. Das ist zwar verschwindend gering, aber ich weiß es und damit ist es für mich nicht schön. Auf meinen Ubuntu-Systemen, konkret dem DNS-Cluster, habe ich es so gelöst, dass ich auf nur einer CARP-Instanz (VHID 53) sowohl das IPv4 also auch das IPv6 abbilde.​
Nun habe ich einen Weg gefunden, wie das auch bei OPNsense gehen kann. Die Idee ist noch nicht erprobt, wurde aber auf github diskutiert.
Lösung: Es wird eine aktive CARP-VHID angelegt, egal ob nun als IPv4 oder IPv6. Dieser einen CARP-VHID wird dann entweder eine virtuelle IPv4 oder IPv6 zugeordnet. Einstellung erfolgt normal über in der OPENsense über "Interfaces / virtuelle IPs / CARP". Für die zweite IP wird nun ein IP-Alias definiert und dieses IP-Alias wird dann an die zuvor definierte eineindeutige VHID des CARP gebunden. Im Ergebnis hat man nun eine CARP-Instanz, die Multicastverkehr erzeugt, und zwei IPs, die von dieser CARP-Instanz verwendet werden.​
Muss ich noch in der Praxis testen, klingt aber erst einmal sehr gut und ist im Prinzip die Lösung, die ich auch unter Ubuntu verwende.


tiermutter schrieb:
@rednag fand einst zB die Zeitsteuerung von FW Rules miserabel (ich nutze sowas nicht).
Zum Vergrößern anklicken....
Zeit gesteuerte Firewall Rules habe ich mir noch nicht so angesehen, weil ich bisher noch keine Verwendung dafür hatte. Vielleicht fällt mir irgendwann mal eine ein, oder jemand erleuchtet mich mit einer sinnstifftenden Anwendung dafür. Ich habe mir aber mal kurz das Prinzip angeschaut...
Was ich so gesehen habe ist, das man beliebige Schedules ("Time Ranges") angelegen kann in der OPNsense und diese dann mit beliebigen Firewall Rules verknüpfen kann. Ich sehe jetzt gerade keine "miserable Einschränkung". Aber auch hier, lasse ich mich gerne erleuchten. ;)
 
Zuletzt bearbeitet:
Glaub das Ding war damals als ich mir das angesehen hatte: Du musstest jeden einzelnen Tag manuell per Klick aktivieren.
Ist aber auch schon eine Weile her. Eventuell hat sich das mittlerweile geändert.
 
rednag schrieb:
Glaub das Ding war damals als ich mir das angesehen hatte: Du musstest jeden einzelnen Tag manuell per Klick aktivieren.
Ist aber auch schon eine Weile her. Eventuell hat sich das mittlerweile geändert.
Zum Vergrößern anklicken....

Das stimmt, wenn man einen bestimmten Tage will, dann muss man dann einzeln auswählen; ansonst kann man sagen "jeden Montag" oder "jeden Montag bis Sonntag" gefolgt vom Wunschzeitfenster.
 
Danke fürs nachsehen. Dann ist das immer noch so. Aber vielleicht stört auch nur mich das.
 
Jap, nur den speziellen rednag :)
Habe zumindest im forum noch nie gesehen, dass das Thema behandelt wurde. Ich denke wenn wirklich Interesse in einer breiteren Masse da wäre, hätte man da schon was getan.
Aber wir wollen mal nicht @Barungar s thread kapern, der ist nämlich scheinbar völlig zufrieden und das gefällt mir viel besser :D
 
tiermutter schrieb:
der ist nämlich scheinbar völlig zufrieden und das gefällt mir viel besser
Zum Vergrößern anklicken....
Völlig zufrieden... stimmt nicht. ;) Ich bin zufrieden und OPNsense macht bisher einen sehr guten Eindruck.

Aber für die Zufriedenheit fehlt noch ein bisschen was. Aber da arbeite ich auch schon dran. Sprich ich werde die Hardware dann doch nochmal tauschen. ;) Ich habe mir schon zwei kleine Boxen auf Basis eines AMD Ryzen™ Embedded V1500B bestellt. Für die beiden NUCs finde ich schon noch eine Verwendung, da bin ich mir sicher; aber der Versuch mit den USB-Netzwerkadaptern war genau das ein Versuch.

Das Schöne am AMD Ryzen™ Embedded V1500B ist, dass der mit 2x 10G kommt.

RyzenV1500B.png
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Zurzeit aktive Besucher

Gesamt: 147 (Mitglieder: 3, Gäste: 144)

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
6.177
Beiträge
60.059
Mitglieder
6.263
Neuestes Mitglied
george

Teilen

Zurück
Oben