OpenVPN Integrierung



  • Hallo,

    hinter der PfSene hängen 2 Netze. In einer davon möchte ich gerne von außerhalb des internen LANs verbinden können, sprich über WAN.
    Habe mir bereits einige Anleitungen dazu angesehen und versucht, dies so zu konfigurieren.

    Leider erhalte ich vom OpenVPN Dienst die Meldung, dass der Deamon nicht erreichbar ist.

    Ich habe schon fast die Vermutung, dass ich bei der Tunnel Konfiguration einen Fehler gemacht habe.
    Wenn ich unter "OpenVPN/Servers/Edit" das entsprechende Netzwerk konfiguriere, frage ich mich, was genau bei "Tunnel Settings" unter "IPv4 Tunnel Network" und unter "IPv4 Local network(s)" einzutragen ist?

    Vielen Dank!



  • Es gibt verschiedene Szenarien (Site2Site, Roadwarrior) mit OpenVPN. Erst mal (er)klären welches genutzt werden soll.

    Dann gibt es zur Einrichtung von OpenVPN-Servern auf pfSense einen "Wizard". Ich habe den zwar noch nie benutzt,
    aber warum sollte er nicht zum Erfolg führen.

    Weiterhin gibt es das Paket "openvpn-client-export". Dieses Paket ist nach meiner Meinung sehr nützlich.
    Viel Spaß mit OpenVPN

    LG



  • Hallo und vielen Dank für die schnelle Antwort!

    Ich benötige eine Verbindung von außerhalb in das LAN. Soweit ich weiß, wird das mit einer "SSL-VPN Roadwarrior" Verbindung / Methode realisiert?

    Den Wizard kenne ich und habe ich genutzt. Daraus resultiert meine Frage :)
    Das Paket habe ich ebenfalls installiert.

    Grüße



  • Hallo,

    SSL-Auth oder SSL + user auth sind die bevorzugten Methoden. SSL bedeutet, dass jeder user ein Client-Zertifikat benötigt, der Server benötigt ein Server-Zertifikat und beide müssen von derselben CA stammen. Die letzten beiden sollte der Wizard automatisch generiert haben, wenn du diese Variante gewählt hast. Das User-Zertifikat musst du für jeden einzelnen User im User-Manager generieren und dabei eben dieselbe CA auswählen.

    Das "Tunnel Network" ist das virtuelle Netz des VPN-Tunnel. Hier einfach ein Netzwerk wählen, das sich mit keinem deiner internen überschneidet, bspw. 10.187.43.0/24. Aus diesem Netz bekommen Server und Clients ihre virtuellen IPs.
    Bei "IPv4 Local network(s)" sind die lokalen Netze anzugeben, die die VPN Clients erreichen könne sollen. Damit wir auf den Client eine Route dafür gesetzt, die den VPN Server (die Tunnel IP des Servers) als Gateway verwendet.

    Wenn der Server nicht starte, schau, ob im Log Hinweise zu finden sind. Status > System Logs > OpenVPN

    Grüße



  • @sessa45 said in OpenVPN Integrierung:

    Ich benötige eine Verbindung von außerhalb in das LAN. Soweit ich weiß, wird das mit einer "SSL-VPN Roadwarrior" Verbindung / Methode realisiert?

    Nun, das ist sowohl mit einem Site2Site Szenarium als auch mit einem Roadwarrior Szenarium möglich.

    Du solltest dich mit den Unterschieden vertraut machen bevor du mit OpenVPN auf pfSense beginnst.
    Es gibt im Netz genügend Quellen zum diesem Thema. Mach dich schlau.

    Speziell zum Roadwarrior Szenarium sollte man im Kopf haben, daß der Aufbau des Tunnel
    nicht so leicht blockiert werden kann. Es gibt da unterschiedliche Ansätze.

    LG



  • Hallo,

    ich habe nun die Anleitung hier (https://www.ceos3c.com/pfsense/configure-openvpn-for-pfsense-2-3-step-by-step/) durchgelesen.
    Während der Konfiguration habe ich keine Möglichkeit gefunden, sie gegannten Arten der Verbindung zu konfigurieren - was aber erst mal nicht weiter tragisch ist.

    Unter "Status -> OpenVPN" sehe ich, dass der Service läuft.
    Die Sobald ich mich jedoch verbinden möchte, erhalte ich folgende Meldung:

    Thu Aug 16 16:25:39 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
    Thu Aug 16 16:25:39 2018 Windows version 6.2 (Windows 8 or greater) 64bit
    Thu Aug 16 16:25:39 2018 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
    Enter Management Password:
    Thu Aug 16 16:25:44 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]89.21.54.197:1194
    Thu Aug 16 16:25:44 2018 UDP link local (bound): [AF_INET][undef]:1194
    Thu Aug 16 16:25:44 2018 UDP link remote: [AF_INET]89.21.54.197:1194
    Thu Aug 16 16:26:44 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Thu Aug 16 16:26:44 2018 TLS Error: TLS handshake failed
    Thu Aug 16 16:26:44 2018 SIGUSR1[soft,tls-error] received, process restarting
    Thu Aug 16 16:26:49 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]89.21.54.197:1194
    Thu Aug 16 16:26:49 2018 UDP link local (bound): [AF_INET][undef]:1194
    Thu Aug 16 16:26:49 2018 UDP link remote: [AF_INET]89.21.54.197:1194
    Thu Aug 16 16:26:53 2018 SIGTERM[hard,] received, process exiting
    

    Folgende Konfiguration seitens des Netzwerkes habe ich vorgenommen:
    Ich selber habe eine interne IP (10.0.1.118/24)

    In der PfSense Konfiguration "VPN -> OpenVPN -> Servers" unter Tunnel Settings habe ich bei "IPv4 Tunnel Network" die "10.0.10.0/24" angegeben. Das Subnetz habe ich jedoch nicht selber angelegt, so habe ich es zumindest laut Anleitung verstanden.
    Hinter der PfSense hängt nur ein Netz (10.0.1.1/24) und halt eben das WAN auf der anderen Seite.

    Weiß jemand Rat?
    Danke



  • So sieht das Log aus, wenn der Client den Server gar nicht erreicht.

    Der Server lauscht auf der WAN Adresse, wie im Tutorial, und die WAN IP ist ein öffentliche oder ist da noch ein Router davor.

    Versuchst du die Verbindung aus dem Netz hinter der pfSense, auf welcher der OpenVPN-Server läuft?



  • @viragomann said in OpenVPN Integrierung:

    So sieht das Log aus, wenn der Client den Server gar nicht erreicht.

    Der Server lauscht auf der WAN Adresse, wie im Tutorial, und die WAN IP ist ein öffentliche oder ist da noch ein Router davor.

    Versuchst du die Verbindung aus dem Netz hinter der pfSense, auf welcher der OpenVPN-Server läuft?

    Nein, da steht kein Router mehr davor. Kommt ungefiltert an der PfSense an.
    Verbindung möchte ich gerne in das Netz hinter der PfSense, also in das igb1 (10.0.1.1/24) Netz.



  • Also versuchst du die Verbindung von außen.
    Dann schau mal mit Hilfe von Packet Capture, ob die VPN-Pakete überhaupt am WAN Interface ankommen.
    Das könnte ja auch durch den ISP blockiert sein.

    Außerdem, eine Verbindung über VPN mit dem Netz 10.0.1.1/24 wird nicht gut funktionieren, wenn du selbst eine IP in diesem Netz hast. Da musst du irgendeine Seite ändern.


  • Moderator

    @sessa45 said in OpenVPN Integrierung:

    ich habe nun die Anleitung hier (https://www.ceos3c.com/pfsense/configure-openvpn-for-pfsense-2-3-step-by-step/) durchgelesen.

    Nur nochmal dazu: es gibt keinen Grund immer irgendwelche komischen oder alten und teils nicht mehr geltenden Tutorials von Drittseiten zu lesen. Vor allem bei der Fehlerbeschreibung kommt dann immer "ja das war nach Anleitung" und dann wird irgendwelche dubiose Doku verwendet. Vor allem nachdem es sowohl offizielle Doku als auch nun das Buch kostenfrei gibt.

    1. https://www.netgate.com/docs/pfsense/vpn/index.html
    2. https://www.netgate.com/docs/pfsense/book/openvpn/index.html
    3. Für VPN gibts immer noch den Wizard/Assistenten

    Musste das bei den ganzen seltsamen Doku/HowTo/Sonstwas Links der letzten Zeit mal loswerden.

    Grüße



  • @viragomann said in OpenVPN Integrierung:

    Außerdem, eine Verbindung über VPN mit dem Netz 10.0.1.1/24 wird nicht gut funktionieren,

    Ich verbinde aus dem 10.0.1.1/24 Netz in das (Bei der PfSense eingestellte) 10.0.10.1/24 Netz.



  • 10.0.10.0/24 ist der Tunnel. Hinter der pfSense liegt nach deiner obigen Info ein das Netz 10.0.1.0/24, das du erreichten möchtest.
    Das geht nicht, wenn dein Rechner selbst eine IP in diesem Segment hat, 10.0.1.118 wie du oben schreibst.



  • Alles klar, ich verstehe!
    Dieses Netz (Der Tunnel) ist doch lediglich dafür da, um mir (Dem Client, der in das Netz hinter der PfSense verbinden will) eine IP zu geben, richtig?

    Ich habe das Netz nun mal abgeändert, sodass das Tunnel Netz nun wie folgt lautet:
    10.10.0.1/24



  • Genau genommen ist der VPN-Tunnel ein Transit-Netz. In diesem hat der Client-Rechner eine IP (am virtuellen Interface) und auch der Server.
    Verbindungen zu Zielen jenseits der VPN werden auf die IP des Servers geroutet, dieser leitet die Pakete an die jeweiligen Zielgeräte weiter.

    Doch das Tunnel-Netz ist ja hier gar nicht das Problem. Sondern, dass dein Rechner (der VPN-Client) eine IP (auf dem anderen Interface) in einem Subnetz hat, das über die VPN zum Server geroutet werden soll. So funktioniert das Routing nicht.
    Da müsste ein Subnetz geändert werden, entweder das clientseitige LAN oder das serverseitige.



  • So, wie viragomann es schon sagte, Ja. Das Tunnelnetzwerk ist zwingend notwendig und darf auf der Sense nicht anderweitig verwendet werden. Setzt du den Haken bei „redirect Gateway“ musst du dein lokales LAN Subnet nicht bei „local networks“ angeben.
    Stelle mal testhalber das Interface auf localhost und füge eine NAT Regel hinzu: 1194 UDP Port auf Interface WAN mit Quelle any und Ziel deine öffentliche IP mit redirect auf localhost. Dann sollte es auch klappen.
    Und zusätzlich eine Outbound NAT Regel für dein Tunnel Subnet.



  • Vielen Dank. Ich habe den VPN Dienst neu konfiguriert und es klappt wunderbar, bekomme eine Verbindung in das gewünschte Netz.

    Habe die Rules ebenfalls so konfiguriert, dass nur http und https funktionieren sollte.
    Leider kommt der Ping (IMCP) aber auch durch, obwohl ich dazu keine Regel definiert habe?

    0_1534939362046_Unbenannt.PNG

    Jemand eine Idee, wieso?
    Selbst, wenn ich alle Regeln deaktiviere, kommt der Ping durch. HTTP und HTTPS gehen dann, wie gewollt, nicht.



  • Was stört dich daran eine externe IP anzupingen? Du könntest eine Regel für ICMP erstellen und diese dann blocken. Diese Regel muss dann ganz oben stehen.

    Und nebenbei, deine erste Regel bewirkt, dass die letzte Regel niemals ausgeführt wird und das ICMP als Protokoll erlaubt ist.



  • @sessa45 said in OpenVPN Integrierung:

    Leider kommt der Ping (IMCP) aber auch durch, obwohl ich dazu keine Regel definiert habe?

    Wodurch? Durch die VPN?
    Ich sehe nicht, was dieser Ping mit der VPN zu tun hat.

    Grundsätzlich muss auf der pfSense alles per Regeln erlaubt werden. Einzige Ausnahme, die mir jetzt einfällt, sind DHCP Requests.



  • Nein, ich meine als geenrelle Einstellung. Hat nichts mit dem VPN zu tun, der läuft.

    Grundsätzlich sollte das IMCP doch blockiert sein? Ich pinge aus dem Netz, welches hinter der PfSense hängt.

    PS: 1.1.1.1 ist eine öffentliche IP (CloudFlare DNS).



  • Ja, nach den gezeigten Regeln dürfte es nicht erlaubt sein.
    Hast du eine Floating-Regel, die es erlaubt.

    Ich habe bei mir eigens eine Floating-Regel für ICMP angelegt. Wenn ich dies deaktiviere, gehen keine Pings.



  • Nein, keine Sonderregeln.
    Nach einem Reboot der PfSense geht der Ping nicht mehr durch ...

    Erstelle ich eine pass regel, führe einen ping aus, deaktivere / lösche diese wieder, geht der ping trotzdem durch...



  • @sessa45 said in OpenVPN Integrierung:

    Erstelle ich eine pass regel, führe einen ping aus, deaktivere / lösche diese wieder, geht der ping trotzdem durch...

    Na ist doch normal so lange der State noch existiert.

    https://www.netgate.com/docs/pfsense/firewall/firewall-rule-basics.html



  • Ja, so lange der State aktiv ist, ist der Ping auch erlaubt. Wenn du den Ping aber für einige Sekunden beendest, wird die Verbindung geschlossen.

    Aktive Verbindungen werden durch Änderungen an Filterregeln nicht beeinträchtigt.
    Wenn du das haben möchtest, müsstest du die die Verbindung manuall kappen. Diagnostic > States