# [ARCHIVIERT] pfSense® mit ExpressVPN TEIL4: Load Balancing / Redundanz / GEO Routing

Dies ist der letzte Teil meiner vierteiligen Reihe zum Thema VPN mit der pfSense®.
In diesem Teil geht es darum, mehrere Tunnel parallel zu betreiben und die Ausgänge damit auch auf die Länder zu verteilen.
Das ist ein Zusatz zum zweiten und dritten Teil!

Folgende Artikel sind bisher erschienen:

• pfSense® mit ExpressVPN TEIL1: Der Tunnel (und Einführung)
• pfSense® mit ExpressVPN TEIL2: Selektives Routing (IP oder Ports
• pfSense® mit ExpressVPN TEIL3: Komplettes Routing

Viel Spass!

VPN Load Balancing / Redundanz

Und nun die Kühr: Was ist besser als ein VPNs? Zwei! oder drei …..
Das Ziel soll hier sein:

• Falls eine VPN Verbindung weg ist, springt die pfSense® auf eine andere VPN Verbindung.
• Sind beide (oder sogar mehr) VPNs aktiv, wird zwischen den verfügbaren Leitungen der Verkehr aufgeteilt (Load Balancing).

Dazu wird das existierende VPN einfach 1:1 nochmal angelegt, es wird dabei nur der Server ausgetauscht,
z.B. netherlands-amsterdam-ca-version-2.expressnetw.com. Der Rest ist gleich.
Die Anzahl der gleichzeitig erlaubten Verbindung variiert von VPN Anbieter zu VPN Anbieter.
Es spräche aber auch nichts dagegen mehrere verschiedene zu nutzen. Hier gibt es keine Einschränkungen.

Hinweis: Der VPN Standort ist der „Ausgang“. An dem kommt euer Paket aus dem VPN Tunnel wieder raus. Was hier zur Vereinfachung der Deutsche Standort war (auch weil am schnellsten), muss für andere Szenarien ggf. ein anderer Standort gewählt werden, um z.B. den Ausgang in den USA zu nutzen.

Hier nutze ich mal als Beispiel germany-frankfurt-1, usa-newyork und netherlands-amsterdam

• germany-frankfurt-1-ca-version-2.expressnetw.com
• usa-newyork-ca-version-2.expressnetw.com
• netherlands-amsterdam-ca-version-2.expressnetw.com

Ob alle VPNs aktiv sind, lässt sich wie immer dann unter Status – OpenVPN nachschauen

Interfaces

Alle neu hinzugefügten VPN Verbindungen werden wie vorher auch als Interfaces hinzugefügt, damit diese als Gateway genutzt werden können.

Achtet darauf, das die Interfaces als Namen nicht zu lang sind. In einer ersten Version des Artikels habe ich immer ExpressVPNgermanyfrankfurt1 genutzt. Das sorgt für Probleme hinterher in der Web Oberfläche. Nutzt einfach germanyfrankfurt1 stattdessen. Böse Falle.

Gateway Gruppe

Nachdem nun alle Interfaces angelegt und benannt wurden, können diese zu einer Gateway Gruppe zusammen gefasst werden.
Unter System – Routing – Gateway Groups wird eine Gruppe angelegt,
z.B. VPNGROUP mit nur den drei OpenVPN Gateways als Tier 1

Das „Tier“ legt die Priorität der Nutzung dar. Haben alle Tier 1, sind diese gleichberechtigt und der Verkehr wird zwischen allen Tier 1 Mitgliedern aufgeteilt (Load-Balancing). Ein Tier 2 würde hier nur dann genutzt, sollten alle Tier 1 Mitglieder nicht zur Verfügung stehen (Failover).
Wobei ein Load-Balancing auch gleichzeitig ein Failover ist.
Daher setzten wir hier alles auf Tier 1 mit Trigger Level Member Down.

Als Besonderheit müssen unter Gateways in den VPN Gateways die Monitor IP geändert werden, da die ExpressVPN Gateways sind leider selber nicht anpingbar sind.
Sonst würde die pfSense® immer davon ausgehen, das der Gateway nicht verfügbar ist.
Daher bekommt jeder Gateway einen externe, zuverlässige IP als Monitoring IP hinterlegt. Da eine IP immer nur einmal vergeben werden kann,
nutzen wir hier der einfachhalthalber die IP Adressen der DNS Server.

Das sieht dann in der Liste so aus:

Den Status und die Erreichbarkeit lässt sich wunderbar unter Status – Gateway ablesen:

Outbound NAT

Soll nun also ein Paket vom Testrechner in Richtung VPN fliegen, dann muss es auf die IP Adresse des VPN Providers übersetzt werden, das haben wir für den ersten VPN aus Teil 2 und Teil 3 ja schon einmal erledigt. Das ist jetzt einfach: Im Outbound NAT wird die existierende Outbound NAT Regel für die erste OpenVPN Verbindung kopiert und nur das Interface wird geändert.

Das sollte dann wieder in der Übersicht so aussehen. Jedes VPN hat ein eigenes Mapping:

Abschließend nicht vergessen mit Apply Changes alles aktiv zu setzen.

Firewall

Mit einer Firewallregel haben wir vorher das Routing bzw. den Gateway zugewiesen, was jetzt aber nicht stimmt, da es nur auf eine VPN Verbindung verweist.
Das wird jetzt in die VPNGruppe geändert. Im LAN Interface der Firewall wird die Regel angepasst:

Unter Show Advanced wird VPNGROUP als Gateway gewählt.

Damit stimmt auch in der Übersicht wieder alles:

Abschließend nicht vergessen mit Apply Changes alles aktiv zu setzen.

Test

Die üblichen Tests aus Teil 3 behalten ihre Gültigkeit.
Mit dieser Seite kann noch überprüft werden, in welchem Land wir gerage rausgekommen sind: http://ifconfig.co/country
Mehrmaliges Neuladen der Seite bringt immer wieder andere Länder zum Vorschein (mit Shift-F5 um den Browser Cache zu übergehen!)

So, damit sind wir am Ende der Reihe angekommen.
Ich freue mich wie immer über Anmerkungen oder Verbesserungsvorschläge.