Multi-WAN default Gateway mit S2S VPN Fragen

p54

Hallo,

ich hätte ein paar Fragen zu Multi-WAN und S2S Verbindungen zwischen zwei Standorten.

Ziel ist es, die Ablösung meiner alten Firewall gegen eine neuere. Mit meinen ersten Test im privaten Umfeld bin ich soweit schon durch und mir gefällt die PFSense außerordentlich gut.

Nun zu meiner Aufgabe. Ich benötige eine Multi-WAN Lösung die es mir erlaubt schnell und einfach, ggf. auch automatisiert die Verbindung zwischen StandortA und StandortB via S2S VPN, wie auch Default-Gateways zu wechseln, gerade HTTP und HTTPs von intern nach extern und übergreifende Routings der RoadWarrior VPN (RW) des anderen Standortes. Sprich der RW-VPN Client der sich bei StandortA verbindet kann auch über die bestenende S2S VPN zu StandortB zugreifen auch mit Wechsel der S2S VPN01 zu VPN02, 03 oder 04.

Dies funktionierte soweit mit meiner alten Lösung recht gut und leicht.

Dazu kämen div. Dienste wie Webserverzugriff, RW-VPN Clients, SMTP zwischen ISP und StandortA über ein festes Gateway (CCC.CCC.CCC.CCC) mit entsprechend der DynDNS bzw. öffentlichen IP (StandortA Public IP: CCC.CCC.CCC.ccc).

Daher die Frage, kann das die PFSense so in dieser Form abbilden, oder ist so etwas in der PFSense nicht vorgesehen?

Gerade der Wechsel zwischen den S2S VPNs wäre ein hohes Kriterium, wie auch div. Routings von intern nach extern des jeweiligen Standort zwei verfügbaren WAN-Schnittstellen, z.B. HTTP/HTTPs Gateway wechsel bei zu hohem treffic oder Leitungsausfall usw.
Auch das Routing der aktiven S2S zwischen den beiden Standorten in Verbindung der Dienste wäre schön, z.B. VPN01 zwischen StandortA & B nur RDP, VPN04 zwischen StandortA & B nur Druckjobs zum jeweiligen Druckerserver/printer, dazu die Möglichkeit dies zu wechseln wenn eine der S2S VPNs down ist (automatisiert oder manuell).

Ich habe hier eine Kurzform meine derzeitige Konfiguration mit den wichtigsten Funktionen versehen. Vielleicht könnt ihr mir hier sagen ob ich das so machen kann, wie ich es mir vorstelle.

Über jede Hilfe und Informationen zu diesem Thema würde ich mich sehr freuen.

VG, p54

JeGr

@p54 Beim ersten Draufschauen würde ich zwar sagen, dass VPN2/3 kompletter Overkill sind aber vielleicht gibts nen triftigen Grund. Ich halte aber wenn ich das sehe nix davon, weil bei 2/3 zum Einen jeweils ein Anbieter down ist und dann beide rest-aktive Tunnel über die gleiche Leitung gehen -> das macht keinen wirklichen Sinn weil es die Bandbreite beschneidet. Meines Erachtens genügt es VPN1/4 aufzubauen, jeweils WAN1 mit WAN1 und WAN2 mit WAN2.

Ich vermute dass dann GW A1 und B1 pfSensen werden sollen? Oder was ist mit den 2ern? Das ist nicht so ganz klar.

Gruß Jens

p54

Hi,

oh sorry, copy&paste fail. Die sollen einfach überkreuz zeigen. Sprich VPN02 geht von StandortB über KabelDeutschland (Public IP:BBB.BBB.BBB.bbb) zu StandortA Telekom (Public IP: CCC.CCC.CCC.ccc).

Und VPN03 geht von StandortB über Telekom (DDD.DDD.DDD.ddd) nach KabelDeutschland StandortA (AAA.AAA.AAA.aaa).

EDIT: Hab das Screen schnell angepasst.

Ja, das mit dem Beschneiden der Leistung ist mir bewusst. Nur möchte ich mir mehr "Möglichkeiten" offen halten falls der Bedarf da wäre. Wie du auch empfiehlst, würde ich primäre mit VPN01 & VPN04 arbeiten, alles andere wäre "Notfall-Optionen" die ich mir gerne bereithalten würde.

Die PFSense soll GATEWAY A1 auf StandortA und GATEWAY B1 auf StandortB. Die B2er Gateways sind andere Firewallsysteme die noch VPN RWs, WLAN, NTP, DMZ, DNS-Proxy (Shella) und MailGateway (SMTP-Proxys) beinhalten. Die müssen vorerst noch bleiben, bis ich hier die Ablösung mit der PFSense in Angriff nehmen kann. Zuerst benötige ich aber die GATEWAYs A1 und GATEWAYs B1 je Standort, damit ich wieder Herr über den Traffic bin ;)

Bisher hatte ich nur ein paar Doks gefunden die Multi-WAN mit der PFSense immer nur als FailOver beschrieben haben. Daher meine Frage zu diesem Thema etwas vorschnell hier im Forum.

Danke für deine Rückmeldung!

VG, p54

JeGr

@p54

Ja, das mit dem Beschneiden der Leistung ist mir bewusst. Nur möchte ich mir mehr “Möglichkeiten” offen halten falls der Bedarf da wäre. Wie du auch empfiehlst, würde ich primäre mit VPN01 & VPN04 arbeiten, alles andere wäre “Notfall-Optionen” die ich mir gerne bereithalten würde.

Kann ich prinzipiell verstehen, aber die bringen dir ja nichts, oder? Beispiel so ich das richtig interpretiere:

A1 und B1 haben 2x WAN via KD und Telekom. Somit - wenn ihr nicht gerade durch die halbe Republik getrennt seid - ist es durchaus nicht unwahrscheinlich, dass bei einem Problem oder Ausfall bei KD auch die andere KD Seite tot oder scheintot ist. Telekom ebenso. Also gehe ich bei einem Down des Providers ggf. sicherer, wenn ich mit der Gegenseite des Providers da gar nichts mehr aufbaue.

Kann ich zwar machen, aber: jetzt funktionieren auf A1 noch beide Links, bei B1 aber nur noch Telekom. Also hängen im guten Fall ca. 50% Bandbreite im Link mit A1WAN1 und die anderen bei A1WAN2 fest. Plus: du musst das auch noch autonom und getrennt routen - es bringt dir aber nichts mehr, weil es auf B1 Seite eh alles auf WAN2 reintröpfelt. Also bringt dann auch die Trennung zwischen den VPN Strecken nichts mehr - die ja eher dafür da sind um die eine VPN Strecke zu entlasten. Sprich: Im Failover Fall wird die Bandbreite durch den geringeren Nenner diktiert - die Ausfallseite. Ein Aufsplitten des Traffics auf der "gesunden" Seite bringt dir dann keinen Mehrwert mehr, verkompliziert aber dein Routing und deine Konfiguration, weil du 4 statt 2 Site2Site Tunnel fährst und die auch noch halbwegs dynamisch umschalten müssen. Wuah ;)

Ich würde da eher vorschlagen: VPN1 geht über A1WAN1 und B1WAN1, VPN2 entsprechend A1WAN2 und B1WAN2. 2 Tunnel plain & simple. Dann obendrauf OSPF Routing mit entsprechenden Gewichtungen, so dass im Normalfall eben Traffic 1,2,5,7,9 über VPN1 und Traffic 3,4,6,8 über VPN2 blubbern. Bei Down eines Tunnels - weil eine Seite ein WAN verloren hat - oder beide! - switcht OSPF auf das andere Gateway rüber. Das haben wir im "kleinen" Rahmen schon bei Alternativstrecken und -anbindungen mit Fallback und klappt autonom und super. Also in einem Setup bei dem bspw. eine feste Verbindung oder Funkstrecke zwischen A und B steht, wo aber auch A mit B via WAN und S2S Tunnel verbunden ist. Dort ein OSPF drauf mit Prio auf direkten Link und Niederprio auf VPN und es passiert genau das: direkter Link A-B unterbrochen, innerhalb eines Pings wird auf VPN GW gewechselt. Strecke wieder da -> sofortiges Rückwechseln auf das alte Standard GW.

Da muss zwar in deinem Fall noch ein wenig mehr Hirnschmalz in das OSPF Setup, aber damit sollte das dann eigentlich ganz autonom und flink hin und her schalten.

Bisher hatte ich nur ein paar Doks gefunden die Multi-WAN mit der PFSense immer nur als FailOver beschrieben haben. Daher meine Frage zu diesem Thema etwas vorschnell hier im Forum.

Active-Active oder auch Loadbalancing wird in den Docs auch beschrieben ;)

https://www.netgate.com/docs/pfsense/routing/multi-wan.html
https://www.netgate.com/docs/pfsense/routing/multi-wan-compatibility.html
https://www.netgate.com/docs/pfsense/routing/load-balancing-uneven-multi-wan-connections.html

Nur bei v6 wird MultiWAN ein wenig kniffelig.

https://www.netgate.com/docs/pfsense/routing/multi-wan-for-ipv6.html

Aber sonst lese ich da jetzt nichts, was nicht gehen sollte. Und mit einem geschickt gebauten OpenVPN Server auf A1 oder B1 kannst du auch problemlos Clients ein Fallback ermöglichen, wenn ein WAN down ist - oder die Clients gleich per RoundRobin auf beide Links verteilen.

Gruß Jens

p54

Hi,

danke für deine Ausführung. Ja, jetzt wo du mir noch ein paar Features übergeben hast, ala OSPF werde ich hier wohl noch etwas mehr Hirnschmalz benötigen ;)

@jegr said in Multi-WAN default Gateway mit S2S VPN Fragen:

Sprich: Im Failover Fall wird die Bandbreite durch den geringeren Nenner diktiert - die Ausfallseite. Ein Aufsplitten des Traffics auf der “gesunden” Seite bringt dir dann keinen Mehrwert mehr, verkompliziert aber dein Routing und deine Konfiguration, weil du 4 statt 2 Site2Site Tunnel fährst und die auch noch halbwegs dynamisch umschalten müssen. Wuah

Okay. Da hast du auch wieder recht. Irgend etwas bleibt dann eh auf der Strecke und macht es nicht einfacher.

Dann mach ich erst einmal mein Ziel auf 2 S2S VPNs...Danke. Melde mich wenn ich noch ein paar Fragen habe nach der Sichtung der Doks. Danke dafür!

VG, p54

JeGr

@p54 Klar gerne. Aber ich denke mit OSPF über die beiden Tunnel und ggf. für RoadWarrior noch ne ordentliche Fallback/Balancing VPN Einwahl wäre da der Optimalfall. :)

p54

Morgen liebe Gemeinde,

ich bin nun dran, wie oben schon beschrieben, die alte Wand gegen die wahnsinns PFSense zu migriern/ tauschen.

Jedoch bei meinem ersten Versuch, scheiterte ich da meine PFSense das routing nicht sauber hinbekommen hat.
Ich habe hier auf den div. Schnittstellen einen block erhalten, wie z.B. für Port 25 der auf ein Subsystem weitergeleitet werden soll, wo mein SMTP-Proxy darauf lauscht:

Sep 15 12:47:55 pfsmu filterlog: 5,,,1000000103,em0,match,block,in,4,0x10,,61,55839,0,none,6,tcp,40,194.AAA.AAA.AAA,194.BBB.BBB.BBB,32752,25,0,A,,3784683105,0,,

Folgende Settings habe ich bisher hinterlegt.

Gateways - primäre sollte GW_WANIR als default gelten:

Statisches Routing:

NAT Setting - auch schon mit NAT + Proxy getestet:

Interfaces:

NAT-Portforward:

NAT-Outbound im Hybrid-Mode:

Firewall Rules WANIR:

Firewall Rules LAN:

Firewall Rules für SMTP-Proxy Interface:

Ins Internet bin ich über die PFSense gekommen aus dem LAN. Jedoch über das Interface für den SMTP-Proxy komme ich nicht rein oder raus :( Habe ich irgendwo etwas übersehen, warum die Anfragen meines SmartHostanbieter von extern nach intern, schon am WANIR Interface geblockt werden und nicht zugestellt werden können. Die Doku zum NAT habe ich schon einmal überflogen, aber half mir auch nciht weiter:

PFSense NAT

Wäre schön wenn jemand meinen Fehler entdecken würde und mich damit einen Schritt weiter bringen könnte.

Danke & VG, p54

JeGr

Das Portforwardings auf den Proxy ist falsch. Als Ziel steht da xy_NET, nicht die xy_address. Das Netz /24 ist keine wirklich sinnvolle Destination für ein Portforwarding, wenn der Hit auf irgendeine IP geht. Die Dest. Address muss die Adresse sein, die von WANIR aus angesprochen wird um den Proxy zu erreichen. Also potentiell die WANIR address. Ansonsten verstehe ich der Regel nicht. Und wie dir dein Log ganz oben schon sagt: der Hit kommt auf EM0 an, also der WANIR 194er Adresse. Dort muss das Forwarding definiert werden.

Gruß

p54

Hallo,

JeGr - danke für deine Rückmeldung. Leider konnte ich es aktiv noch nicht testen, da hier alles im live-Betrieb ist, aber ich habe mein Setting nach deiner Unterstützung hin angepasst. Mal sehen ich ob damit weiter komme. :)

Ich habe jedoch noch ein Problem zu meiner lan2lan bzw. peer2peer VPN. Ich kann dies z.G. ohne Unterbrechung testen, da ich zuhause schon meine alte Firewall gegen die PFSense gewechselt habe. Nun bin ich dabei das erste Szenario zu tesen, wie ich es temporär schaffen könnte eine vpn zwischen pfsense und zeroshell zu bewerkstelligen.
Wenn da jemand etwas Erfahrung und Zeit hätte, kann sich gern einmal hier https://forum.netgate.com/topic/136997/vpn-site-to-site-between-zeroshell-and-pfsense/2 umsehen und mir gerne meine Fehler nennen, sollte hier einer eingeschlichen haben.
Ich weiß zeroshell ist hier nicht das Produkt, aber um die Migration durchführen zu können brauche ich eine Übergangslösung bis ich auch den anderen Standort mit einer pfsensen versehen kann. Wie auch immer, schon im Voraus vielen Dank!

VG, p54