How-To-Compute

IT-Pro Blog: Anleitungen, Tipps und Tricks um euch das Leben leichter zu machen.

Portunity OpenVPN-Tunnel mit Endian Firewall

Für mein Demolab wollte ich gerne eigene öffentliche IPv4-Adressen zum erschwinglichen Preis haben und bin nach einem Hinweis von Stefan Wendrich beim Anbieter Portunity gelandet. Besonders cool finde ich die Möglichkeit die öffentlichen IP-Adressen an jedem handelsüblichen DSL-Anschluss zu betreiben oder sogar den Internet Provider zu wechseln ohne die IP-Adressen wechseln zu müssen und das zu einem super Preis. Für mein Demolab habe ich einen kleinen Server zuhause stehen, auf dem Windows 10 mit VMWare Workstation läuft. Mittels VMWare Workstation wollte ich eine virtuelle Firewall bereitstellen, welche sowohl den OpenVPN Tunnel zu Portunity herstellt, als auch das Routing und Firewalling für mein Demolab übernimmt. Portunity selbst empfiehlt für diesen Zweck die PfSense Firewall und hat dafür auch eine entsprechende Anleitung veröffentlicht. Leider finde ich die PfSense Firewall nicht besonders benutzerfreundlich und habe mich daher nach einer Alternative für mein Lab umgeschaut, diese sollte natürlich im Idealfall kostenfrei sein. Dank Stefan bin ich dann bei der Community Edition der Endian Firewall gelandet. Benutzerfreundlichkeit und Funktionsumfang entsprachen genau dem was ich mir vorgestellt hatte. Besonders gut gefiel mir auf Anhieb die Aufteilung der Interfaces in RED (WAN), ORANGE (DMZ) und GREEN (LAN). Etwas Tricky wurde es dann allerdings bei der Konfiguration des OpenVPN Tunnels in Richtung Portunity. Daher hier eine kleine Anleitung zum Thema:

Mein Setup:

  • Endian Firewall Community Edition (Free)
  • VMWare Workstation VM mit 512MB Ram, 20GB HD, 1CPU und 3 Netzwerkkarten:
    • Eth0 | Bridged | WAN | RED | Netz: 192.168.0.0/24 | InterfaceIP: 192.168.0.2 (1 ist mein Router im “phyischem” LAN)
    • Eth1 | VMNet1 | DMZ | ORANGE | Netz: 192.168.1.0/24 | InterfaceIP: 192.168.1.1 (virtuelles Netz für meine DMZ VM´s)
    • Eth2 | VMNet2 | LAN | GREEN | Netz: 192.168.2.0/24 | InterfaceIP: 192.168.2.1 (virtuelles Netz für meine LAN VM´s)

Die Firewall fungiert für das ORANGE und GREEN als Default Gateway.

Konfiguration:

Nachdem ihr die VM konfiguriert, die Endian vom ISO installiert und die Grundkonfiguration vorgenommen habt, könnt ihr per z.B. 192.168.2.1:10443 auf die Webkonsole der Endian zugreifen. Die Standardzugangsdaten lauten:

Benutzer: admin

Kennwort: endian

Nachdem ihr auch dort den Erstkonfigurationswizard durchgeklickt habt, empfehle ich, euch per WinSCP mit dem Management Interface der Endian zu verbinden, folgende Datei zu bearbeiten und wie folgt anzupassen:

/etc/openvpn/openvpnclient.conf.tmpl

An dieser Stelle kommt uns der Abschnitt Advanced Configuration in der Anleitung von Portunity zugute:

Advanced configuration

Zuletzt fügen Sie in das Feld Advanced folgendes ein:

client;
tun-mtu 1440;
fragment 1400;
mssfix;
auth-retry interact;
persist-key;
persist-tun;
ns-cert-type server;
verb 0;
auth-user-pass /conf/portunity.login;
redirect-gateway;

Einfach den Text kopieren und die entsprechenden Werte in die o.g. Datei einfügen und wie im Screenshot gezeigt anpassen. Den Punkt auth-user-pass könnt ihr euch dabei sparen, die Zugangsdaten für den OpenVPN-Tunnel werden an anderer Stelle eingegeben.

Das war auch schon der wichtigste Schritt. Die restliche Konfiguration findet im GUI der Firewall statt.

VPN –> OpenVPN client (Gw2Gw) –> Add tunnel configuration

Die benötigten Zertifikate bekommt ihr hier auf der Portunity Webseite. Anschließend müsst ihr die Eingabemaske um folgende Werte ergänzen:

Connection name: Einfach nur ein Name
Connect to: euer OpenVPN-Gateway, bekommt ihr von Portunity
Upload certificate: das im Vorfeld heruntergeladene ca.crt auswählen
PKCS#12 challenge password: kann frei bleiben
Die Zugangsdaten solltet ihr von Portunity bereitgestellt bekommen haben.
Remark: Bemerkungen

Unter advanced tunnel configuration müsst ihr die Werte wie folgt anpassen:

Jetzt erst mal abspeichern und die Regel noch einmal bearbeiten, denn erst jetzt bekommt ihr den “geheimen” dritten Abschnitt der OpenVPN Konfiguration zu Gesicht. Hier müsst ihr die ta.key Datei einspielen, die Direction auf 1 (Client) umstellen und natürlich wieder speichern.

Sofern ihr alles richtig gemacht habt, sollte das Ganze danach in etwa so aussehen.

Soweit so gut! Der VPN Tunnel steht jetzt. Wenn ihr jetzt aber wollt, das beispielsweise eure LAN Systeme im Internet surfen können, werdet ihr mit Sicherheit feststellen, dass dies nicht funktioniert. Durch den Parameter: redirect-gateway in der openvpnclient.conf.tmpl wird die Default-Route auf der Firewall automatisch über den OpenVPN Tunnel geschickt. Das ist natürlich toll für die Systeme die darüber erreichbar sein sollen. Aber nicht für die Systeme die einfach über euren normalen Internetanschluss raus sollen. Wenn ihr auf eurer Firewall unter: Status –> Network status –> Routing Table Entries schaut, könnt ihr die entsprechende Route dort sehen:

Das Weglassen des redirect-gateway Parameters hat uns an dieser Stelle übrigens nicht weitergeholfen.

Nach einigem rumprobieren mit Stefan, haben wir uns damit beholfen eine Policy-based-Route zu setzen.

Diese Route besagt ganz einfach das alle Systeme aus dem Netz “Green” in Richtung “ANY” über den “Main uplink” und nicht über den OpenVPN-Tunnel geschickt werden. In meinem Fall habe ich die Route so ergänzt, dass dies nur für die Ports 80 und 443 gilt. Sämtlicher übriger Traffic wird über den OpenVPN-Tunnel gejagt. Nun brauche ich nur noch entsprechende Firewallregeln erstellen und kann meine Systeme auf diese Weise von Extern verfügbar machen, mit eigenen öffentlichen IP-Adressen.

Ich hoffe euch hilft dieser Artikel weiter. Solltet ihr noch Fragen oder Anregungen haben, schreibt einfach einen Kommentar.

Viel Spaß

Dennis

1 Comment

Add a Comment
  1. Hi Dennis,
    ich habe das grade nachgebaut und immer folgende Meldung im OpenVPN Log bekommen.
    do_ifconfig, tt->did_ifconfig_ipv6_setup=1
    RTNETLINK answers: Permission denied

    Über den Thread habe ich dann herausgefunden, das IPv6 aktiviert sein muss, auch wenn es nicht genutzt wird!
    https://0xacab.org/leap/bitmask-dev/issues/5917

    Dazu in der /etc/sysctl.conf IPv6 aktivieren

    net.ipv6.conf.all.disable_ipv6 = 0
    net.ipv6.conf.default.disable_ipv6 = 0
    net.ipv6.conf.lo.disable_ipv6 = 0

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

How-To-Compute © 2017 Frontier Theme