OPNsense Forum
International Forums => German - Deutsch => Topic started by: c. schenk on April 02, 2018, 10:44:19 pm
-
Hallo,
bin gerade dabei, Multi WAN zu konfigurieren. Die entsprechenden gateways und Gruppen habe ich angelegt. Nun habe ich ein paar Verständnisfragen zu den firewall Regeln. Dazu habe ich ein screenshot angefügt.
Die Regeln 2-4 entsprechen der Scheunentorregel unter 1, richtig?
Muss ich jede Regel 3-fach für jede gateway Gruppe anlegen?
Habe lt. Anleitung die DNS Regel (5) angelegt. Entfällt dadurch die Regel unter (6)?
-
Ich nehme mal dein Schaubild zuhilfe um dir das besser zu erklären.
Du hast bei "2" ja bereits einen Loadbalancing Eintrag für beide Gateways erstellst, also zusammengefasst. Du müsstest dieses Gateway jetzt nur in deinen Regeln bei "4" einstellen. Natürlich kannst du auch fest, eines deiner beiden Gateways wie bei "3" und "4" von dir erstellt deinen Einzeleinträgen zuweisen. Dann wird eben nur dieses eine Gateway benutzt.
Dein Scheunentor hast du allerdings in den Regeln "1-4" bereits richtig erkannt. Denn die Regeln werden von oben nach unten abgearbeitet.
Wenn du an deinen Computern nicht Unbound auf der OPNsense nutzen möchtest und ein im Internet vorhandener DNS Server benutzt werden soll, macht Regel "5" keinen sinn, denn 172.16.0.0 bis 172.31.255.255 ist ein Privater IP Adressbereich welcher im Internet nicht geroutet wird, also kann da auch kein DNS Server sein. Ist auf der 172.29.180.200 allerdings ein Interner DNS-Server, solltest du den bei Source eintragen, sonst kann dieser nicht auf das Internet zugreifen.
Regel "6" ist in Ordnung, wenn jeder Computer im LAN net unbeschränkten DNS Zugriff erhalten soll, egal über welches Gateway auch immer. Allerdings kannst du dann Regel "5" löschen, da diese dann auch mit meinem Änderungsvorschlag sinnlos wäre.
-
Danke für die Antwort. Allerdings habe ich es noch nicht richtig verstanden. Bei Anleitungen zur pfsense werden diese 3 Regeln als Standard angegeben und die DNS Regel ist aus der opnsense Doku.
Die Scheunentorregeln sollen deaktiviert und die Regeln unterhalb der "4" sollen für ein load balance und failover angepasst werden. Da fehlt mir noch die Logik dazu.
-
Danke für die Antwort. Allerdings habe ich es noch nicht richtig verstanden. Bei Anleitungen zur pfsense werden diese 3 Regeln als Standard angegeben und die DNS Regel ist aus der opnsense Doku.
Die Scheunentorregeln sollen deaktiviert und die Regeln unterhalb der "4" sollen für ein load balance und failover angepasst werden. Da fehlt mir noch die Logik dazu.
Im Pfsense Screenshot ist gemeint, das du zuerst dort wo die Gateways definiert sind, Failover und Loadbalancing Groups erstellst. Die du dann in den jeweiligen Firewallregeln unterhalb von "4" einstellen kannst. Die DNS Regel aus dem OPNsense Wiki/Doku besagt nur, dass du auf dem LAN Interface Zielport 53 auf die LAN adress zeigend erstellen sollst, aber nur dann wenn die Computer in deinem LAN OPNsense auch als DNS Server nutzen sollen. Falls sie ohne Umweg einen DNS Server im Internet nutzen sollen, gilt das gleiche wie für die anderen Regeln unter "4".
-
ok, habe nun die allow any Regeln deaktiviert, die DNS Regel gelöscht, Standardprotokolle auf die gateway group load balance und die IPsec Verbindungen auf Failover WAN 1 eingestellt. Ist das so richtig?
-
ok, habe nun die allow any Regeln deaktiviert, die DNS Regel gelöscht, Standardprotokolle auf die gateway group load balance und die IPsec Verbindungen auf Failover WAN 1 eingestellt. Ist das so richtig?
Ja so hatte ich das auch gemeint. Ich empfehle dir trotzdem mal ein bisschen mit dem Failover und Load Balancing zu "spielen", so bekommst du ein besseres Verständnis dafür. Angefangen mit einem simulierten WAN Ausfall.
-
Prima, dann habe ich es jetzt verstanden :)
Sobald mein 2. Modem da ist, werde ich mit unterschiedlichen Szenarien testen.
Danke für die Unterstützung.
-
Einen pfSense Post von 2013 :o Warum schaut eigentlich nie jemand auf die DOKU Seiten der Projekte um mal AKTUELLE Infos zu lesen? (https://doc.pfsense.org/index.php/Category:Multi-WAN bspw.)
Auch wenn ich AUSFALL_WAN_1 und 2 nicht verstehe. Ich vermute mal das sollte eher heißen "WAN1_Fallback_WAN2" und umgekehrt, also Prio liegt auf WAN1 und im Notfall dann Schwenk auf WAN2.
Die werden also sinnvoll nur da genutzt, wo man genau ein spezifisches Interface priorisieren möchte und kein LB Verhalten möchte. Das sollte man sich im bestimmten Fall auch genau überlegen, da das auch schonmal Probleme machen kann. Stichwort Online Shops und Session Dropping.
Gruß
-
Auch wenn ich AUSFALL_WAN_1 und 2 nicht verstehe. Ich vermute mal das sollte eher heißen "WAN1_Fallback_WAN2" und umgekehrt, also Prio liegt auf WAN1 und im Notfall dann Schwenk auf WAN2.
Die werden also sinnvoll nur da genutzt, wo man genau ein spezifisches Interface priorisieren möchte und kein LB Verhalten möchte. Das sollte man sich im bestimmten Fall auch genau überlegen, da das auch schonmal Probleme machen kann. Stichwort Online Shops und Session Dropping.
Bei "AUSFALL_WAN_1 und 2" bin ich davon ausgegangen, das Fallback gemeint ist. Wie die Gatewaygruppe jemand nennt überlasse ich ihm aber selbst. Session Dropping beim Loadbalancing kann leicht passieren, da dies ja schließlich kein echtes Loadbalancing mittels Routing Protokoll ist. Wobei ich zugebe an die Doku von Pfsense habe ich nicht wirklich gedacht, sonst hätte ich sie verlinkt.
-
Ich habe die Gateway's nur anders benannt, entspricht aber fallback.
Ich habe die docu zu pfsense auch gelesen. Ich hatte nur den alten thread genommen, da da der Eintrag in deutsch ist. In der docu habe ich als Laie keinen Unterschied entdeckt. Was habe ich da übersehen?
Die firewall Regeln sollen so sein, dass der normale traffic über das load balancing gleichmäßig verteilt werden soll. Die Verbindungen, die über den auf einem Rechner installierten VPN- client laufen, sollen bevorzugt über WAN 1 laufen.
Aus der opnsense docu habe ich die sticky connection übernommen. Das habe ich so verstanden, dass ich damit kein session dropping habe. Habe ich das richtig interpretiert?
Am Samstag soll endlich das 2. Modem kommen, dann kann ich mit dem Testen beginnen.
-
Ist schon so richtig, wie du das gemacht hast. Meine Antwort im vorherigen Post, war nur für @JeGr.
Sticky Connections sind auch richtig, das grenzt einen ausgehenden Client Pro Verbindung auf ein WAN GW ein, allerdings nur so lange, wie dein Client eine Verbindung nach außen aufgebaut hat, und States in der PF Tabelle vorhanden sind die deinem Client zugeordnet sind. So werden unterschiedliche Clients und Verbindungen dann gleichmäßig auf 2 und mehr WAN GWs verteilt. Das ganze aber wie gesagt nur Verbindungsbasierend.
Und HTTP und HTTPs Verbindungen bleiben ja nicht unbedingt geöffnet nachdem eine Webseite geladen ist. (Ajax und Websockets mal beiseite) Würde es auch bei Sticky Connections passieren das zufällig das andere GW umgeschaltet wird, und der Zielwebserver deine Session je nach Programmierung als ungültig erkennt.
Aber unbedingt sorgen machen würde ich mir ehrlich gesagt da nicht. Denn dann hätten die ganzen Unitymedia und Kabeldeutschlandkunden enorme Probleme beim aufrufen von IPv4 Webseiten, da beide Provider Hosted CG-NAT benutzen, um IPv4 den Kunden bereitzustellen. Und das sogenannte Carrier-Grade-NAT funktioniert ähnlich wie das Loadbalancing hier.
Der einzige unterschied ist der, das ein öffentlicher IP Adressbereich dort mittels IGP bekannt gemacht wird. Und mehreren NAT-Routern zugewiesen wird. Sodass jedes Interface mehrere IP-Adressen dieses Subnetzes konfiguriert bekommt.
Bsp. Intf. 1 RTR1: 80.72.0.0 - 80.72.0.64
Bsp. Intf. 2 RTR1: 80.72.0.65 - 80.72.0.128
Bsp. Intf. 1 RTR2: 80.72.0.129 - 80.72.0.192
Bsp. Intf. 2 RTR2: 80.72.0.193 - 80.72.0.254
usw.
Und dann werden darüber die Verbindungen Dynamisch Genatted (Source-NAT) ähnlich dem Loadbalancing Prinzip in der Sense.
Und so viele IPs sind da nötig, da über eine IP nur 65550 Ports Theoretisch genutzt werden können.
-
Da ichs oben nicht gesehen hatte - an welcher Stelle war den sticky connections konfiguriert? :)