OpenVPN auf Raspberry Pi

[EmanuelJ]

Hallo,
Ich möchte einen OpenVPN Server auf meinem Raspberry Pi einrichten, der es mir ermöglichen soll, mich aus dem Internet mit meinem Heimnetz zu verbinden und dort auf meine Geräte zuzugreifen. Ich verwende hierfür einen Raspberry Pi 3, der über LAN mit meiner Fritzbox verbunden ist. Ich habe zur Installation folgende Anleitung genutzt:

https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installieren/

Diese Anleitung wurde mir von meinem Dozenten empfohlen, der letztens VPN und Proxy mit uns durchgegangen ist. Ich versuche das erlernte Wissen zu verarbeiten aber irgendein Fehler raubt mir seit Wochen den letzten Nerv.

Ich habe bei mir zuhause eine Fritzbox 7490, die mir von meinem Provider vor einigen Jahren gestellt wurde. Mein Internetanschluss war DS-Lite und wurde dann auf meine Anfrage zu einem dual-stack Anschluss umgestellt. Ich bekomme also eine IPv4 und eine IPv6 Andresse von meinem Provider. Dieser DS-Lite Anschluss war bei mir lange ein unbekanntes Problem, doch nachdem ich einen dual-stack Anschluss bekam funktionierte wenigstens die Fritzbox eigene VPN Verbindung mittels IPsec. Ich habe hierfür eine Domäne bei Strato gekauft und diese auf DynDNS konfiguriert. Ich kann also von meinem Handy über IPsec eine VPN Verbindung herstellen, allerdings nur zur Fritzbox, nicht aber zum Pi. Außerdem ist meine Fritzbox nun über meine Domäne aus dem Internet erreichbar und konfigurierbar.

Ich habe für meinen Pi eine Portweiterleitung eingerichtet, von extern 61452 auf intern 1194.

Außerdem gibt es noch eine Weiterleitung für ssh mit dem Port 22356 auf intern 22.

Die SSH Weiterleitung funktioniert tadellos aber aus irgendeinem Grund will die VPN Weiterleitung nicht funktionieren. Ich bekomme auf meinem Smartphone immer diese Meldungen:
Die geschwärzten Stellen verdecken die IPv4 Adresse vom Router. DynDNS ist also nicht das Problem...

Der Code 111 bezeichnet den Fehler, dass der Port 61452 nicht offen ist.
Scheinbar stimmt also etwas mit der Portfreigabe nicht?

Meine openvpn.conf und das .ovpn Profil sehen wie folgt aus:

Hier habe ich den Port in 61452 geändert. Das Bild stammt noch aus einem Test... Die blaue Stelle verdeckt meine Domäne...

Ich hoffe, man kann mir hier endlich helfen. Mein Dozent, der Admin der Fakultät und ein paar andere, einschließlich mir selbst, sind mit absolut ratlos. 😂 Hoffentlich habe ich nichts vergessen, habe mittlerweile einen Tunnelblick in dieser Sache.

 

[till69]

Probier doch erst mal einfach einen anderen Port ... ich nehme gerne 443, da dieser bei vielen Firewalls komplett (also auch für UDP) offen ist. Also extern 443 auf intern 443.

Und wenn es nur darum geht, vom Handy ins Heimnetz zu kommen, würde ich www.wireguard.com probieren ... Setup in 5 Minuten, ebenfalls UDP, aber deutlich schneller.

 

[0x8100]

lass doch erstmal die fritzbox aus dem spiel und verbinde dich innerhalb deines netzes direkt auf den raspi (nicht vergessen port 1194 statt des externen 61452 dann zu nehmen). und dann schau in der /var/log/openvpn.log nach, ob der client überhaupt mit dem server spricht.

 

[EmanuelJ]

Probier doch erst mal einfach einen anderen Port ... ich nehme gerne 443, da dieser bei vielen Firewalls komplett (also auch für UDP) offen ist. Also extern 443 auf intern 443.

Nö, hat nicht geklappt...

Und wenn es nur darum geht, vom Handy ins Heimnetz zu kommen, würde ich www.wireguard.com probieren ... Setup in 5 Minuten, ebenfalls UDP, aber deutlich schneller.

Es geht mir darum, das erlernte Wissen anzuwenden und einen praktischen Nutzen daraus zu beziehen. Ich suche keine Lösung, wo jemand anders die ganze Arbeit für mich schon gemacht hat.

 

[EmanuelJ]

lass doch erstmal die fritzbox aus dem spiel und verbinde dich innerhalb deines netzes direkt auf den raspi (nicht vergessen port 1194 statt des externen 61452 dann zu nehmen). und dann schau in der /var/log/openvpn.log nach, ob der client überhaupt mit dem server spricht.

Also ich weiß jetzt nicht so genau wie ich das anstellen soll. Ich habe mal in das Logfile geschaut (/var/log/openvpn), da steht logischerweise auch nichts drin, weil die Verbindung ja nie zustande gekommen ist.

Ergänzung (27. April 2019)

Ich habe mal mit nmap einen Portscan an meiner IP durchgeführt, nur Port 8089 und 5060 sind offen. Von meinen Ports 22356 und 61452 bzw 443 ist nichts zu sehen. Warum funktioniert dann aber die ssh Verbindung über tcp?

 

[0x8100]

statt der externen ip deiner fritzbox bzw. deiner dyndns adresse verwendest du im openvpn client einfach die interne ip deines raspi (192.168.x.x) und port 1194.

du kannst natürlich auch erstmal nmap auf den raspi selbst machen, um zu schauen ob dort der port überhaupt erreichbar ist (ich geh mal davon aus, dass der openvpn server läuft).

 

[Raijin]

Punkt 1:
Wenn man den externen Port eines Services ändert, muss man den internen Port am Server nicht zwangsläufig mitändern. Man kann den ssh daher problemlos intern auf 22 laufen lassen und den - in meinen Augen unnötig - veränderten Port über die Portweiterleitung realisieren. Ein geänderter Port gilt aber als "security by obscurity" und bietet keinen relevanten Sicherheitsgewinn. Wenn ssh fachgerecht abgesichert ist - zB keine Passwortlogin, sondern via Zertifikat - sowie durch zB fail2ban zusätzlich geschützt ist, kann ssh problemlos auf Port 22 verbleiben, auch extern. Den Port zu ändern ändert hingegen nichts daran, dass man dies ebenso tun sollte!

Punkt 2:
Ein Portscan kommt später. Zunächst musst du mittels "netstat -tulpen" prüfen ob der OpenVPN-Server überhaupt läuft. Dann schaust du dir mit "iptables -L" ob der VPN-Port auch in der INPUT Chain erlaubt ist. Nun prüfst du ob du dich lokal aus dem eigenen (W)LAN mit der lokalen IP des PI verbinden kannst. Anschließend checkst du mit "tcpdump" (+ passendem Filter) ob überhaupt Daten ankommen, während du von außen eine Verbindung versuchst.

 

[EmanuelJ]

statt der externen ip deiner fritzbox bzw. deiner dyndns adresse verwendest du im openvpn client einfach die interne ip deines raspi (192.168.x.x) und port 1194.

du kannst natürlich auch erstmal nmap auf den raspi selbst machen, um zu schauen ob dort der port überhaupt erreichbar ist (ich geh mal davon aus, dass der openvpn server läuft).

Der Port 1194 beim Pi wird von nmap nicht erreicht, nur der Port 22 ist offen...

Der andere Vorschlag hat auch nicht funktioniert. Ich bekomme wie immer CONNECTION REFUSED Code 111

Ergänzung (27. April 2019)

Punkt 1:
Wenn man den externen Port eines Services ändert, muss man den internen Port am Server nicht zwangsläufig mitändern. Man kann den ssh daher problemlos intern auf 22 laufen lassen und den - in meinen Augen unnötig - veränderten Port über die Portweiterleitung realisieren. Ein geänderter Port gilt aber als "security by obscurity" und bietet keinen relevanten Sicherheitsgewinn. Wenn ssh fachgerecht abgesichert ist - zB keine Passwortlogin, sondern via Zertifikat - sowie durch zB fail2ban zusätzlich geschützt ist, kann ssh problemlos auf Port 22 verbleiben, auch extern. Den Port zu ändern ändert hingegen nichts daran, dass man dies ebenso tun sollte!

Punkt 2:
Ein Portscan kommt später. Zunächst musst du mittels "netstat -tulpen" prüfen ob der OpenVPN-Server überhaupt läuft. Dann schaust du dir mit "iptables -L" ob der VPN-Port auch in der INPUT Chain erlaubt ist. Nun prüfst du ob du dich lokal aus dem eigenen (W)LAN mit der lokalen IP des PI verbinden kannst. Anschließend checkst du mit "tcpdump" (+ passendem Filter) ob überhaupt Daten ankommen, während du von außen eine Verbindung versuchst.

Zu Punkt 1:
Danke schonmal für diese Info. Ich will erstmal, dass der Server funktioniert, danach kümmere ich mich um die nötige Sicherheit. Das mit dem Zertifikat statt Passwort-Login war sehr nützlich, das werde ich definitiv machen. Danke dafür

Zu Punkt 2:
"netstat -tulpen" gibt es bei mir nicht als Befehl. "netstat -s" sagt mir auch nur, dass es bereits UDP Pakete gab aber nicht über welchen Port...

iptables -L gibt mir folgendes aus:

Ich kann damit leider nichts anfangen...

Falls du das mit der lokalen IP des Pi verbinden so meinst wie 0x8100, das hat nicht funktioniert.

tcpdump (sofern das überhaupt udp zeigt) hat bei mir mit "tcpdump -i eth0" nur die SSH Verbindung gezeigt. Von der IP meines Handys fehlt jedoch jede Spur...

 

[Raijin]

Speziell bei ssh gibt es eigentlich kein "Sicher mach ich das später" weil das zu den ersten Schritten überhaupt gehört.

Wie dem auch sei, ich wundere mich, dass netstat bei dir nicht funktioniert. Die Parameter -tulpen sind eigentlich Standard, tcp, udp, listen, program, extended und numeric. Schau sonst mal in die man page bei raspbian, evtl ist da eine andere Version von netstat drauf (man netstat). Unter Umständen gibt es da einen der Parameter noch nicht oder so. Wenn der Befehl funktioniert, sollte er dir aber alle geöffneten Ports nebst der jeweiligen Anwendung anzeigen. D.h. Da müsste dann der OpenVPN-Server mit dem konfigurierten Port auftauchen sowie der ssh-Server und was auch immer sonst noch für Dienste auf dem PI laufen. Nur dann, wenn hier auch der gewünschte Port auftaucht, ist überhaupt eine Anwendung aktiv, die auf eingehende Verbindungen wartet. Ist keine Anwendung auf dem Port aktiv, kann auch keine Verbindung zustande kommen, weil das Betriebssystem eingehende Pakete dann direkt ablehnt.

Wenn man einen Server ins Netz stellt, sollte man sich tunlichst auch mit der Firewall auseinandersetzen. iptables ist die Firewall von Linux bzw. Das Frontend für das dahinter liegende netfilter-System. In deinem Screenshot sieht man, dass

• jedes eingehende Paket, das an den Server selbst gerichtet ist, erlaubt wird (INPUT >> Default ACCEPT)
• jedes eingehende Paket, das weitergeleitet werden soll, erlaubt ist (FORWARD >> Default ACCEPT)
• jedes ausgehende Paket erlaubt ist (OUTPUT >> Default ACCEPT)

Im Klartext heißt das, dass die Firewall den Traffic nicht blockieren wird, weil alles per default erlaubt ist. Wenn nun also bei netstat dein VPN-Port als Listening angezeigt wird und dort auch für alle source IPs freigeben ist (da steht dann bei source sowas wie 0.0.0.0:*), dann steht dem VPN zumindest innerhalb des (W)LANs nichts im Wege. Du solltest also vom Handy im WLAN oder von einem anderen PC/Laptop aus eine Verbindung zum OpenVPN-Server auf dem PI herstellen können, wenn du in der Client.conf bei remote die lokale IP des PI eingibst. Klappt das, ist der VPN-Server soweit funktionstüchtig.


tcpdump kann sowohl tcp als auch udp cappen.

tcpdump -i eth0 udp and port 1234

Wenn die Portweiterleitung am Router stimmt, solltest du hier in jedem Fall Traffic sehen, wenn du dich vom Handy aus verbindest. Zum test erstmal wieder nur bei einer Verbindung innerhalb des lokalen Netzwerks versuchen und wenn du da was siehst, kannst du es vom www aus versuchen.

 

[EmanuelJ]

Wenn der Befehl funktioniert, sollte er dir aber alle geöffneten Ports nebst der jeweiligen Anwendung anzeigen. D.h. Da müsste dann der OpenVPN-Server mit dem konfigurierten Port auftauchen sowie der ssh-Server und was auch immer sonst noch für Dienste auf dem PI laufen

SSH ist zu sehe und auch auf LISTEN aber der Port 1194 nicht...

Wenn die Portweiterleitung am Router stimmt, solltest du hier in jedem Fall Traffic sehen, wenn du dich vom Handy aus verbindest.

Keine Ahnung was das für ein Port sein soll (55366) aber die IP ist jedenfalls von meinem Handy...

Scheinbar läuft der VPN Server gar nicht. Wie kann ich den denn starten? Gibt es da einen bestimmten Befehl?
Mir ist nur "service openvpn start" , stop, restart und status bekannt.

 

[EmanuelJ]

Aus dem Internet kommen die Pakete also auch an. Scheint wohl wirklich nur an dem nicht gestarteten OVPN Dienst zu liegen.

 

[Raijin]

Die hohen Quell-Ports sind die, die das OS des Smartphones als Absendeport ausgewählt hat. Der VPN-Server muss ja auch irgendwohin antworten und die IP allein reicht nicht. Sofern das nicht explizit vom Service vorgegeben ist, wählt das Betriebssystem den Antwortport automatisch (Linux ab 32768, Windows ab 49152).

Scheint wohl wirklich nur an dem nicht gestarteten OVPN Dienst zu liegen.

So sieht's aus. Wir haben jetzt alles geprüft. Das Handy ist nicht geblockt (im Mobilfunk werden zT einige Ports blockiert), die Portweiterleitung funktioniert und die Firewall lässt alles durch. So wie es aussieht fehlt in der Tat nur noch der Server

Schau mal in \var\syslog bzw. \var\messages sowie in das OpenVPN-Log ob da irgendwas gemeldet wird, wenn der Server startet. Unter Umständen hast du einen Fehler in der server.conf und deswegen startet OpenVPN nicht richtig.

 

[EmanuelJ]

Ich glaube wir sind der Lösung nahe...😇

Das Log-File von openvpn zeigt mir als root folgendes:

(Das ganze Log ist voll damit, sonst steht da nix drin)

Im syslog steht folgendes:

Im message log steht folgendes:

So sieht meine openvpn.conf aus:

 

[0x8100]

in meiner config sind die pfadangaben relativ zum /etc/openvpn verzeichnis. probier mal

ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key
dh easy-rsa/keys/dh1024.pem

und schau nach, ob diese dateinen auch existieren.

 

[EmanuelJ]

und schau nach, ob diese dateinen auch existieren.

Hmmm, habe das Problem gefunden... 🥺
Im openvpn.conf steht bei mir unter dh folgendes: "dh easy-rsa/keys/dh1024.pem".
In genau diesem Ordner ist aber schon eine Datei dh2048.pem.
Ich habe also in der .conf die 1024 auf 2048 erhöht und schon hat alles funktioniert...🤩

Danke an alle hier in diesem Thema. Ihr habt mir echt viel geholfen, auch wenns am Ende nur so eine Kleinigkeit war. Jetzt werde ich mich erstmal um die Sicherheit kümmern und einiges ausprobieren. Ich habe da schon etwas gefunden, das nicht funktioniert. Sollte ich das nicht selbst hinbekommen, pack ich das aber in ein neues Thema...

 

[Raijin]

Freut mich, dass es nu klappt. Jetzt hast du auch ein paar Werkzeuge kennengelernt, mit denen man an so ein Problem herangeht.

Solange der VPN-Server nur @ home bzw. hinter einer Portweiterleitung liegt, ist die Firewall (iptables) eher sekundär, weil der Router bereits alles abhalten sollte. Wenn du aber irgendwann so einen Server mal voll ins Netz stellst - zB auf einem gemieteten vServer - musst du dich zwingend auch damit auseinandersetzen, weil der Server sonst im worst case offen ist wie ein Scheunentor.

Auch so kann es nicht schaden, sich damit zu beschäftigen. Ich sage das, weil dein erster Beitrag impliziert, dass es sich in irgendeiner Form um ein Studium handelt, das sich zumindest am Rande mit IT beschäftigt.