VPN Verbindung wird nicht aufgebaut

  • Nabend Zusammen,


    ich versuche gerade auf meinem RPI2 noch zusätzlich einen OpenVPN Server einzurichten. Der Raspberry fungiert schon als Client. Allerdings komme ich nicht durch meinen Router, obwohl dort der Port geöffnet ist.


    Bei anderen Diensten(FTP,SSH) funktioniert die Port Weiterleitung, nur VPN klappt nicht an diesem Standort. Als Router verwende ich einen Linksys E3000 mit Tomatousb. Weil die Portfreigabe für andere Dienste funktioniert, kann ich mir nicht vorstellen, dass da der Fehler liegt.
    Andererseits klappt die Verbindung, wenn ich die Verbindung aus dem internen Netz direkt zum Raspberry aufbaue. D.h. demnach müsste es doch an der Port Weiterleitung liegen :s


    Ihr seht ich stehe gerade vor nem größeren Dilemma. Ich Poste mal meine Config, vllt könnt ihr damit was anfangen.


    Client (Notebook mit Debian)



    Server:



    Mittels "ifconfig" sehe ich, dass OpenVPN zwei TUN Devices initialisiert hat (tun0 und tun1, für Client und Server)


    Die Client Config vom Raspberry zur Info



    Fehlermeldung wenn ich versuche die Verbindung extern aufzubauen ist der typische

    Code
    TLS Error: TLS handshake failed


    Ports habe ich mehrfach kontrolliert und stimmen überein.


    Habt ihr noch ne Idee wo der Fehler liegen könnte?


    Gruß
    Lutz


  • Vielleicht kannst du dich mal schlau machen, ob UDP von "no-ip" unterstützt wird!


    BTW: Warum soll no-ip oder andere DDNS-Provider, UDP nicht "unterstützen"? Mit Hilfe der DDNS-Provider und der Namensauflösung (DNS) kommt man lediglich an die externe/öffentliche IP-Adresse ran (... wenn der DDNS-Client & Co. richtig "funktioniert"). Das hat mit VPN, ob per TCP oder per UDP, nichts zu tun.



    Automatisch zusammengefügt:
    [hr]


    Weil die Portfreigabe für andere Dienste funktioniert, kann ich mir nicht vorstellen, dass da der Fehler liegt.


    Client (Notebook mit Debian)


    Server:

    Code
    dev tun1
    port 50200
    proto udp


    Starte auf deinem PI mit dem OpenVPN-Server:

    Code
    sudo tcpdump -c 5 -vvveni eth0 udp port 50200


    bevor Du mit dem Debian-Client, aus dem Internet! die Verbindung zum Server herstellst.


    "Aus dem Internet!" bedeutet: von einem anderen Internetanschluss (... und nicht von dem an dem auch der Server angeschlossen ist).


    Siehe danach die Ausgabe von tcpdump.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited once, last by rpi444 ().

  • Laut deinen Configs hört der Server auf 50200udp und der Raspi-Client verbindet zu 50146udp

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Edited once, last by Der_Imperator ().


  • Laut deinen Configs hört der Server auf 50200udp und der Raspi-Client verbindet zu 50146udp


    Ja, aber er hat auch einen Debian-Client, mit "xyz.no-ip.info 50200".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Ja, aber er hat auch einen Debian-Client, mit "xyz.no-ip.info 50200".


    Ja, aber er schreibt das es mit dem raspberry durch den Router nicht klappt.
    Kein Ton wegen dem Debian durch Router und schon gar nicht wo nun der Server drauf läuft.
    Wahrscheinlich auf dem Debian Notebook, deswegen auch

    Quote

    Mittels "ifconfig" sehe ich, dass OpenVPN zwei TUN Devices initialisiert hat (tun0 und tun1, für Client und Server)


    Nur wenn ich den falschen Port anspreche wird das nix.
    Mit auch nur einer Zeile aus den Logs steht man da und muß wieder in die Glaskugel schauen.
    Also Ockhams Rasiermesser : Der Port im Clienten ist faslch. :angel:

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.


  • Kein Ton wegen dem Debian durch Router ...



    BTW: Ich habe es aus:

    Quote


    Andererseits klappt die Verbindung, wenn ich die Verbindung aus dem internen Netz direkt zum Raspberry aufbaue.


    , versucht abzuleiten. ;)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Welchen Port hast du auf dem Router wie freigegeben?


    * den externen Port auf den gleichen internen Port
    * den externen auf einen anderen internen Port



    zu 1:
    im Internet wird der Port 12345 verwendet, der vom Router auf den Port 12345 des Zielsystems im eigenen Netz weitergeleitet wird,


    zu 2:
    im Internet wird der Port 12345 verwendet, der vom Router auf den Port 54321 des Zielsystems im eigenen Netz weitergeleitet wird,


    Verbinden musst du dich bei dem 'externen' Gerät (also dem in Internet) auf den Port, der am Router freigegeben ist. Nicht auf den Port, auf dem OpenVPN läuft.



    Des weiteren muss natürlich auf beiden Seiten TUN bzw TAP verwendet werden, und UDP bzw. TCP. Die dann auch entsprechend freigegeben werden müssen.

    Selber denken,
    wie kann man nur?


  • Server:

    Code
    ...
    client-to-client
    ...


    Für die VPN-Verbindung zwischen Client und Server, solltest Du den Server nicht mit "client-to-client" konfigurieren.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Für die VPN-Verbindung zwischen Client und Server, solltest Du den Server nicht mit "client-to-client" konfigurieren.


    client-to-client besagt dass die Clients untereinander kommunizieren dürfen.

    Quote

    --client-to-client
    Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface.


    When this option is used, each client will "see" the other clients which are currently connected. Otherwise, each client will only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rules.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.


  • client-to-client besagt dass die Clients untereinander kommunizieren dürfen.


    Das ist richtig, aber dann gibt es Probleme bei der Kommunikation zwischen dem Server und dem Client. Der 1. Schritt sollte hier m. E., eine funktionierende Kommunikation zwischen dem Server und dem Client sein und wenn das funktioniert, dann kann der TE, sein VPN noch immer für die Kommunikation "client-to-client" konfigurieren/ergänzen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Hi Leute, erstmal danke für eure zahlreichen Antworten.


    rpi444


    Die Ausgabe von tcpdump sieht folgendermaßen aus:



    Zur Info: Der OpenVPN Server hört aktuell auf den Port 22222. Also nicht wundern ;). Im Router ist weiterhin Port 50200 offen. Der Router leitet den externen Port 50200 also an den internen Port 22222 weiter.


    Ich habe "client-to-client" mal auskommentiert. Brachte keine Besserung.


    Der_Imperator


    Bei mir Läuft 1 Raspberry. Auf diesem läuft ein OpenVPN Client und ein OpenVPN Server. Der Port 50146 wird für die Verbindung vom OpenVPN Client des Raspberry benutzt, hat also nix mit dem OpenVPN Server zu tun.


    Nochmal kurz zusammengefasst:

    • OpenVPN Client auf Raspberry Port 50146
    • OpenVPN Server auf Raspberry Port 22222(Im Router extern freigegeben 50200 --> intern 22222)
    • Debian Notebook


    Wie kommst du darauf, dass auf dem Debian der Server läuft? Im ersten Satz schreibe ich doch schon: "ich versuche gerade auf meinem RPI2 noch zusätzlich einen OpenVPN Server einzurichten. Der Raspberry fungiert schon als Client.


    Log Datei vom Server:

    Code
    Sat Apr 23 11:30:52 2016 79.237.17.151:49838 TLS: Initial packet from [AF_INET]111.111.x.x:49838, sid=2fc7cf69 6725a727
    Sat Apr 23 11:31:29 2016 111.111.x.x:35368 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Sat Apr 23 11:31:29 2016 111.111.x.x:35368 TLS Error: TLS handshake failed
    Sat Apr 23 11:31:29 2016 111.111.x.x:35368 SIGUSR1[soft,tls-error] received, client-instance restarting
    Sat Apr 23 11:31:31 2016 111.111.x.x:53567 TLS: Initial packet from [AF_INET]111.111.x.x:53567, sid=880339fd 35c3ecce


    Vielleicht kannst du damit ja mehr anfangen. Ich hatte nur die eine Zeile gepostet, weil meiner Meinung nach die Fehlermeldung genug aussagt bzw. ich aus den anderen keine weiteren Informationen entnehmen kann.

    Edited once, last by Lutz3D ().

  • Code
    root@raspberrypi:/etc/openvpn# tcpdump -c 5 -vvveni eth0 udp port 22222
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    11:15:02.149827 c0:c1:c0:eb:18:0b > b8:27:eb:92:63:ea, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 61, id 4204, offset 0, flags [DF], proto UDP (17), length 42)
       79.237.xxx.xxx.42436 > 192.168.99.4.22222: [udp sum ok] UDP, length 14


    Die Portfreigabe (Router/PI) ist OK.


    Wenn Du auf dem PI einen VPN-Server hast, dann brauchst Du auf diesem PI, nicht auch noch den VPN-Client (für dieses VPN), es sei denn Du willst dich mit diesem VPN-Client zu einem ganz anderen VPN verbinden.
    Lass mal in der config des VPN-Server das "client-to-client" weg und danach schauen wir weiter.



    Automatisch zusammengefügt:
    [hr]


    Ich habe "client-to-client" mal auskommentiert. Brachte keine Besserung.


    Code
    Sat Apr 23 11:30:52 2016 79.237.17.151:49838 TLS: Initial packet from [AF_INET]111.111.x.x:49838, sid=2fc7cf69 6725a727
    Sat Apr 23 11:31:29 2016 111.111.x.x:35368 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Sat Apr 23 11:31:29 2016 111.111.x.x:35368 TLS Error: TLS handshake failed
    Sat Apr 23 11:31:29 2016 111.111.x.x:35368 SIGUSR1[soft,tls-error] received, client-instance restarting
    Sat Apr 23 11:31:31 2016 111.111.x.x:53567 TLS: Initial packet from [AF_INET]111.111.x.x:53567, sid=880339fd 35c3ecce


    Hast Du beim Anlegen/Erstellen des Schlüssels für den VPN-Client, bei "Common Name" den Namen des Clienten eingetragen?


    Versuch mal auch auf Client und Server, mit:

    Code
    auth RSA-SHA512
    tls-cipher DHE-RSA-AES256-SHA
    cipher AES-256-CBC


    (oder gleichwertig) in der config-Datei.


    EDIT:


    Poste von deinem PI (Server), auch die Ausgabe von:

    Code
    sudo iptables -nvx -L

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited once, last by rpi444 ().

  • Ich hab 2 Standorte, die ich mit dem Pi bedienen will. Daher halt auch Server und Client auf einem Pi.


    Ja hab ich. Sonst könnte sich der Client aus dem internen Netz ja nicht am Server authentifizieren.



    IPTables spuckt folgendes aus:



    Gruß


  • Ich hab 2 Standorte, die ich mit dem Pi bedienen will. Daher halt auch Server und Client auf einem Pi.


    Habe ich ja vermutet. Hat aber mit deinem Problem hier nichts zu tun, oder warum hast Du das hier erwähnt? Funktioniert die Verbindung von deinem VPN-Client (auf dem PI) zu dem anderen VPN-Server? Wo befindet sich der andere VPN-Server?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Der andere VPN Server läuft auch auf einem Pi und befindet sich bei meinen Eltern. Der Tunnel zu meinen Eltern funktioniert problemlos.


    Irgendwie macht das alles nicht wirklich Sinn, bin schon kurz davor mir einfach n neuen Pi zu kaufen. Wobei das auch nicht die wahre Lösung ist :s :-/


  • ..., bin schon kurz davor mir einfach n neuen Pi zu kaufen. ...


    Warum willst Du einen neuen PI kaufen? Was soll mit deinem jetzigen PI nicht in Ordnung sein?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden