[Gelöst] OpenVPN durch SSH tunneln - keine Verbindung

[JohnDoe42]

Hallo zusammen,

zunächst die Ausgangssituation:
Auf der Box läuft ein OpenVPN-Server, zu dem ich mich auf "normalem" Wege von einem Windows-Client fehlerfrei verbinden kann.
Nun möchte ich (alternativ) die VPN-Verbindung durch einen SSH-Tunnel über mehrere Stationen aufbauen. Dazu habe ich den Tunnel zunächst wie folgt angelegt:

ssh -v -L1194:localhost:1194 user@host1

ssh -v -L1194:localhost:1194 user@host2

Der OpenVPN-Server benutzt als proto tcp und lauscht natürlich auf Port 1194.
Wenn ich nun einen Verbindungsversuch starte, passiert Folgendes (bitte nicht meckern wegen des Screenshots, ich komme aktuell leider nicht an einen Konsolen-Log):

Hat jemand eine Idee, was da schief laufen könnte ?
Beste Grüße,

JD.

 

[koyaanisqatsi]

Moin

Idee: localhost ist normalerweise nicht ausserhalb der Box zu erreichen.
Nimm entweder 0.0.0.0 oder die IP der fritz.box.
Schau mal mit: netstat -tlep
Alle Server auf localhost werden so von AVM vor externen Zugriff geschützt gestartet.

 

[JohnDoe42]

Der "localhost" in den SSH-Tunneln ist doch jeweils der SSH-Server .. (?)
Nochmal konkret: Ich beginne bei meinem VPN-Client(-Rechner) mit

ssh -v -L1194:localhost:1194 user@host1

Auf der Shell von Host 1 geht das dann weiter:

ssh -v -L1194:localhost:1194 user@host2

Hier ist der localhost doch der Host 1 ...

 

[RalfFriedl]

Und auf host2 läuft OpenVPN über TCP? Mach das ganze oben nochmal ohne die Option -v, bei den vielen Meldungen übersieht man leicht, wo es tatsächlich Probleme gibt.

 

[JohnDoe42]

Nein, auf dem dritten und letzten läuft OpenVPN auf TCP Port 1194.
Wenn ich -v weglasse, ergibt sich auf dem letzten Host (auf welchem der VPN-Server läuft) nur

channel2: open failed: connect failed

Hier ein bischen mehr Log:

Könnte das Problem an

socket: Address family not supported by protocol

liegen ? Desweiteren liest man immer mal, daß in einer solchen Konstellation ein

socks-proxy 127.0.0.1 1194

vonnöten wäre ... allerdings klappt da der Handshake nicht:

Fri Nov 07 12:04:53 2014 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Jun  3 2013
Enter Management Password:
Fri Nov 07 12:04:53 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Nov 07 12:04:53 2014 Need hold release from management interface, waiting...
Fri Nov 07 12:04:54 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Nov 07 12:04:54 2014 MANAGEMENT: CMD 'state on'
Fri Nov 07 12:04:54 2014 MANAGEMENT: CMD 'log all on'
Fri Nov 07 12:04:54 2014 MANAGEMENT: CMD 'hold off'
Fri Nov 07 12:04:54 2014 MANAGEMENT: CMD 'hold release'
Fri Nov 07 12:04:54 2014 Control Channel Authentication: using 'S:\OpenVPNKeys\ta.key' as a OpenVPN static key file
Fri Nov 07 12:04:54 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Nov 07 12:04:54 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Nov 07 12:04:54 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 07 12:04:54 2014 Attempting to establish TCP connection with [AF_INET]127.0.0.1:1194
Fri Nov 07 12:04:54 2014 MANAGEMENT: >STATE:1415358294,TCP_CONNECT,,,
Fri Nov 07 12:04:54 2014 TCP connection established with [AF_INET]127.0.0.1:1194
Fri Nov 07 12:04:54 2014 socks_handshake: TCP port read failed on recv()
Fri Nov 07 12:04:54 2014 SIGTERM[soft,init_instance] received, process exiting
Fri Nov 07 12:04:54 2014 MANAGEMENT: >STATE:1415358294,EXITING,init_instance,,

Ohne den Socks-Proxy sieht das Ganze am Client so aus:

Fri Nov 07 12:10:00 2014 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Jun  3 2013
Enter Management Password:
Fri Nov 07 12:10:00 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Nov 07 12:10:00 2014 Need hold release from management interface, waiting...
Fri Nov 07 12:10:00 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Nov 07 12:10:00 2014 MANAGEMENT: CMD 'state on'
Fri Nov 07 12:10:00 2014 MANAGEMENT: CMD 'log all on'
Fri Nov 07 12:10:00 2014 MANAGEMENT: CMD 'hold off'
Fri Nov 07 12:10:00 2014 MANAGEMENT: CMD 'hold release'
Fri Nov 07 12:10:00 2014 Control Channel Authentication: using 'S:\OpenVPNKeys\ta.key' as a OpenVPN static key file
Fri Nov 07 12:10:00 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Nov 07 12:10:00 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Nov 07 12:10:00 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 07 12:10:00 2014 MANAGEMENT: >STATE:1415358600,RESOLVE,,,
Fri Nov 07 12:10:00 2014 Attempting to establish TCP connection with [AF_INET]127.0.0.1:1194
Fri Nov 07 12:10:00 2014 MANAGEMENT: >STATE:1415358600,TCP_CONNECT,,,
Fri Nov 07 12:10:00 2014 TCP connection established with [AF_INET]127.0.0.1:1194
Fri Nov 07 12:10:00 2014 TCPv4_CLIENT link local: [undef]
Fri Nov 07 12:10:00 2014 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:1194
Fri Nov 07 12:10:00 2014 MANAGEMENT: >STATE:1415358600,WAIT,,,
Fri Nov 07 12:10:00 2014 Connection reset, restarting [0]
Fri Nov 07 12:10:00 2014 SIGUSR1[soft,connection-reset] received, process restarting
Fri Nov 07 12:10:00 2014 MANAGEMENT: >STATE:1415358600,RECONNECTING,connection-reset,,
Fri Nov 07 12:10:00 2014 Restart pause, 5 second(s)
Fri Nov 07 12:10:04 2014 SIGTERM[hard,init_instance] received, process exiting
Fri Nov 07 12:10:04 2014 MANAGEMENT: >STATE:1415358604,EXITING,init_instance,,

 

[RalfFriedl]

Nein, auf dem dritten und letzten läuft OpenVPN auf TCP Port 1194.

Welcher dritte und letzte? Wo läuft das OpenVPN?
Wenn ich es richtig sehe, machst Du folgendes:

client $ ssh -L1194:localhost:1194 user@host1
host1 $ ssh -L1194:localhost:1194 user@host2
host2 $
host2 $ telnet localhost 1194

Was passiert, wenn Du den telnet Befehl auf host2 eingibst? Läuft OpenVPN auf host2 oder auf host3?

 

[JohnDoe42]

Ich hatte den Host 3 aus Gründen der Übersichtlichkeit weggelassen, da sich das Ganze ja nur n-fach wiederholt ...
Ich benutze auf jedem Host (n):

ssh -L 1194:localhost:1194 user@host(n+1)

Telnet ist hier nirgendwo im Spiel. OpenVPN läuft auf Host 3, welcher der letzte der Reihe ist, und von diesem stammen auch die Screenshots.

 

[koyaanisqatsi]

Mit telnet guckst du nur was da läuft...

 telnet openelec 22
SSH-2.0-OpenSSH_6.3

 

[JohnDoe42]

Pardon, Mißverständnis ..
Geht auch Dein Tip mit netstat -tlep ?


Der OpenVPN-Server läuft da wirklich und ganz bestinmmt in Echt auf dem letzten Host auf TCP 1194. Versprochen.

 

[PeterPawn]

Ich sehe zugegebenermaßen nicht richtig durch, was Du am Ende erreichen willst, würde das aber eher systematisch angehen, bis die notwendige Konfiguration klar ist:

1. SSH-Tunnel und OpenVPN-Server erst einmal so weit trennen, daß anstelle des OpenVPN ein simples "nc" genommen wird, was bei erfolgreichem Connect irgendeinen Text zur Gegenseite schickt.

2. Den Tunnel Stück für Stück aufbauen, also erst nur einen Hop vom ersten Client und dort (nach dem Aufbau des Tunnels mit dem ssh-Befehl) ebenfalls mit einem simplen "nc" schauen, ob der Text rauskommt. Klappt das, den Tunnel bis zum "Ende" verlängern.

3. Erst dann würde ich an beiden Tunnelenden die gewünschten Programme (OpenVPN-Server und -Client) verwenden.

Das schließt dann auch die simple (aber zugegebenermaßen auch unwahrscheinliche) Erklärung, daß der OpenVPN-Socket nicht weiterleitbar ist, weil er auf ein "connect" ohne unmittelbar folgende Daten sofort mit einem "close" (am Ende ein FIN) reagiert, sicher aus. Es gibt ja auch den TLS-AUTH-Schutz gegen DoS bei UDP, keine Ahnung, wie das für TCP-Tunnel umgesetzt wird vom OpenVPN - ein kompletter 3-Wege-Handshake ohne Authentifizierung wäre ja auch ein DoS-Angriffspunkt und sei es durch "Client essen Handle auf".

Wenn ich mir den Screenshot aus #1 ansehe und tippen müßte, würde ich annehmen, daß der Hop davor nicht auch eine FRITZ!Box mit Freetz ist (Du sagst ja, der Screenshot stammt vom OpenVPN-Server) und dann würde ich sagen, daß Du auch auf der FRITZ!Box noch einmal ein ssh-Kommando startest. Das gehört da meiner Meinung nach aber nicht hin, denn das Stück des SSH-Tunnels, das in den OpenVPN-Socket münden muß, ist der vom vorletzten Hop per SSH-Kommando zum letzten Hop initiierte Tunnel.
EDIT: Also noch einmal deutlicher: Auf dem letzten Hop vor dem Server würde ich eher ein Kommando wie "ssh -L 1194:<openvpn_server>:1194" verwenden. Wenn Du unbedingt auch auf dem letzten Hop auf localhost:irgendwas am OpenVPN-Server weiterleiten willst, müßtest Du m.E. einen anderen lokalen Port für den Tunnel verwenden, ansonsten wird bei einem '-L 1194:...' ja ein "listen" auf diesem Port vom SSH-Server initiiert und da ist aber schon der OpenVPN-Server aktiv.

Wenn man das netstat ansieht ... warum lauscht da OpenVPN auf dem 443 (https) ?

 

[RalfFriedl]

Ich hatte den Host 3 aus Gründen der Übersichtlichkeit weggelassen, da sich das Ganze ja nur n-fach wiederholt ...

Es hat vermutlich keine besonderen Grund, dass Du nicht einen oder zwei SSH Tunnels verwendest, sondern gleich drei? Eine direkte Verbindung wäre sicherlich besser.

Telnet ist hier nirgendwo im Spiel. OpenVPN läuft auf Host 3, welcher der letzte der Reihe ist, und von diesem stammen auch die Screenshots.

Es ging nicht darum, ob telnet im Spiel ist, sondern dass man telnet zur Diagnose einsetzen kann.
Die Screenshots stammen vermutlich vom Client und nicht von einem der Hosts.

Also die Frage von oben nochmal anders:

client $ ssh -L1194:localhost:1194 user@host1
host1 $ ssh -L1194:localhost:1194 user@host2
host2 $ ssh -L1194:localhost:1194 user@host3
host3 $
host3 $ telnet localhost 1194

Client baut eine Verbindung auf zu host1, dieser zu host2, dieser zu host3, Du hast dann eine Shell auf host3. Kann in dieser Shell telnet eine Verbindung zu localhost 1194 aufbauen?

Der OpenVPN-Server läuft da wirklich und ganz bestinmmt in Echt auf dem letzten Host auf TCP 1194. Versprochen.

Das netstat von Busybox reagiert sowieso nicht auf -e. Nimm statt dessen netstat -ntpl. Ich würde aus dem Bild eher herauslesen, dass da kein openvpn läuft, aber ohne die Option -n bei netstat kann man sich da nie sicher sein.

 

[PeterPawn]

Ich würde aus dem Bild eher herauslesen, dass da kein openvpn läuft, aber ohne die Option -n bei netstat kann man sich da nie sicher sein.

Ich sehe da eine Zeile:

tcp 0 0 0.0.0.0:https 0.0.0.0:* LISTEN 22713/openvpn

in Zeile 4.

Wenn man jetzt mal annimmt, daß weder das openvpn-Binary umbenannt wurde, noch die /etc/services irgendwie geändert wurde, ist das für mich ein OpenVPN-Prozess (wenn er LISTEN macht, wohl auch ein Server) mit der PID 22713.

Also würde ich dafür plädieren, daß der Service durchaus läuft, aber eben auf 443 ... und dann sollte der letzte Hop imho mit "-L 1194:<fritzbox_ip_or_name>:443" gestartet werden bzw. wenn es auf der FRITZ!Box mit dem VPN-Server auch noch einmal über localhost gehen muß (keine Ahnung, warum), dann mit "-L 1194:localhost:443".

 

[JohnDoe42]

Hallo zusammen,

ich bin einen Schritt weiter. Ich habe PeterPawns Idee aufgegriffen und zunächst mal kontrolliert, ob der Tunnel funktioniert. Und siehe da: Schon auf dem Weg klappten einige Verbindungen nicht. Nun habe ich stattdessen Port 8080 verwendet, da scheinbar die Weiterleitung von Port 1194 (oder 443) auf einigen Stationen zwischendurch restriktiv gehandhabt wurde. Nun kann ich nach

ssh -L 8080:localhost:8080 user@host1
...
ssh -L 8080:localhost:81 user@host3

im Browser mit

127.0.0.1:8080

auf das jenseitige Freetz-WebIF zugreifen.
Den Test mit OpenVPN werde ich später nochmal durchführen.

@ RalfFriedl:
Doch. es hat einen besonderen Grund, warum ich drei Hops verwende.
Hier der Output von netstat -ntpl:

root@fritz:/var/mod/root# netstat -ntpl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      10799/openvpn
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      913/dsl_control
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      8324/dropbear
tcp        0      0 0.0.0.0:8118            0.0.0.0:*               LISTEN      22840/privoxy
tcp        0      0 :::49000                :::*                    LISTEN      1063/upnpd
tcp        0      0 :::80                   :::*                    LISTEN      1058/ctlmgr
tcp        0      0 :::81                   :::*                    LISTEN      23653/httpd-webcfg
tcp        0      0 :::53                   :::*                    LISTEN      1105/multid
tcp        0      0 :::22                   :::*                    LISTEN      8324/dropbear
tcp        0      0 :::8182                 :::*                    LISTEN      1058/ctlmgr
root@fritz:/var/mod/root#

@ PeterPawn:

Du hättest Recht gehabt ....
Früher horchte der Dienst auf Port 443, allerdings glaubt ich, den Port eben zu Testzwecken auf Port 1194 geändert zu haben ...
Die einzige Fritzbox ist die "am Ende", also die, auf der Dropbear und OpenVPN laufen.

 

[RalfFriedl]

Schon auf dem Weg klappten einige Verbindungen nicht. Nun habe ich stattdessen Port 8080 verwendet, da scheinbar die Weiterleitung von Port 1194 (oder 443) auf einigen Stationen zwischendurch restriktiv gehandhabt wurde.

Normalerweise spricht nichts gegen Port 1194, es ist ja ein Port oberhalb von 1024 und damit auch nicht grundsätzlich anders als 8080. Es kann natürlich sein, dass 1194 (oder auch 8080) auf einem der rechner unterwegs bereits anderweitig belegt ist. Das sollte dann aber eine Meldung geben, wenn die Verbindung aufgebaut wird.

Früher horchte der Dienst auf Port 443, allerdings glaubt ich, den Port eben zu Testzwecken auf Port 1194 geändert zu haben ...

Ich hätte oben deutlicher schreiben sollen kein Prozess auf dem openvpn Port und nicht kein Prozess.

 

[JohnDoe42]

Es kann natürlich sein, dass 1194 (oder auch 8080) auf einem der rechner unterwegs bereits anderweitig belegt ist. Das sollte dann aber eine Meldung geben, wenn die Verbindung aufgebaut wird.

Das habe ich auch gehofft, allerdings gab es lediglich beim Versuch, Port 443 weiterzuleiten die Meldung, daß bestimmte (eben solche "Key-Ports") weiterzuleiten nur root vorbehalten sei. Und dies bin ich nicht auf allen Hops.

 

[RalfFriedl]

Port 443 ist auch unter 1024, im Gegensatz zu 1194.

 

[JohnDoe42]

Hallo zusammen,

nochmal ein Update:
Nachdem ich ein kleines Problem mit dem OpenVPN-Service auf der Zielbox identifiziert habe (es reichte nicht, den Port in der GUI zu ändern, man mußte auch den Dienst einmal neu starten, damit dieser auf dem neuen Port lauscht), kann ich nun eine OpenVPN-Verbindung zur Zielbox durch den SSH-Tunnel herstellen. Allerdings wird diese sofort wieder gekappt, sobald Pakete kommen. Genauer gesagt wird die SSH-Verbindung gekappt. Hier mal die Logs ->

Server:

Nov 10 10:11:46 fritz authpriv.info dropbear[1157]: Child connection from 131.220.162.137:36622
Nov 10 10:11:47 fritz kern.warn kernel: [1702949.660000] [0]system-load 2  71 tasks:0 % curr:dropbear(0 %) max:dropbear(0 %, pid:1157), readytorun: 1, pgfault 216/s (max 1 avg 1.0)
Nov 10 10:11:51 fritz authpriv.notice dropbear[1157]: Password auth succeeded for 'root' from 131.220.162.137:36622
Nov 10 10:11:57 fritz daemon.notice openvpn[648]: TCP connection established with [AF_INET]127.0.0.1:35214
Nov 10 10:11:57 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 TLS: Initial packet from [AF_INET]127.0.0.1:35214, sid=c7a78d3f a3f94b9f
Nov 10 10:12:00 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 VERIFY OK: depth=1, C=DE, ST=*, L=*, O=*, OU=*, CN=ca, emailAddress=*
Nov 10 10:12:00 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 VERIFY OK: depth=0, C=DE, ST=*, O=*, OU=*, CN=client01, emailAddress=*
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: 127.0.0.1:35214 [client01] Peer Connection Initiated with [AF_INET]127.0.0.1:35214
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: MULTI: new connection by client 'client01' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username t
Nov 10 10:12:01 fritz daemon.notice openvpn[648]: MULTI_sva: pool returned IPv4=192.168.1.100, IPv6=(Not enabled)
Nov 10 10:12:03 fritz daemon.notice openvpn[648]: client01/127.0.0.1:35214 PUSH: Received control message: 'PUSH_REQUEST'
Nov 10 10:12:03 fritz daemon.notice openvpn[648]: client01/127.0.0.1:35214 send_push_reply(): safe_cap=940
Nov 10 10:12:03 fritz daemon.notice openvpn[648]: client01/127.0.0.1:35214 SENT CONTROL [client01]: 'PUSH_REPLY,route-gateway 192.168.1.1,route 192.168.1.0 255.255.255.0,route 192.168.1.0 255.255.255.0,redirect-gateway,ping 10,ping-restart 120,ifconfig 192.168.1.100 255.
Nov 10 10:12:05 fritz daemon.notice openvpn[648]: client01/127.0.0.1:35214 MULTI: Learn: 00:ff:17:4f:1f:12 -> client01/127.0.0.1:35214
Nov 10 10:13:22 fritz daemon.err openvpn[648]: client01/127.0.0.1:35214 Connection reset, restarting [0]
Nov 10 10:13:22 fritz daemon.notice openvpn[648]: client01/127.0.0.1:35214 SIGUSR1[soft,connection-reset] received, client-instance restarting
Nov 10 10:13:22 fritz authpriv.info dropbear[32583]: Exit (root): Exited normally

Client:

Mon Nov 10 10:14:21 2014 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Jun  3 2013
Enter Management Password:
Mon Nov 10 10:14:21 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Nov 10 10:14:21 2014 Need hold release from management interface, waiting...
Mon Nov 10 10:14:22 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Nov 10 10:14:22 2014 MANAGEMENT: CMD 'state on'
Mon Nov 10 10:14:22 2014 MANAGEMENT: CMD 'log all on'
Mon Nov 10 10:14:22 2014 MANAGEMENT: CMD 'hold off'
Mon Nov 10 10:14:22 2014 MANAGEMENT: CMD 'hold release'
Mon Nov 10 10:14:22 2014 Control Channel Authentication: using 'S:\OpenVPNKeys\ta.key' as a OpenVPN static key file
Mon Nov 10 10:14:22 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 10 10:14:22 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 10 10:14:22 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 10 10:14:22 2014 MANAGEMENT: >STATE:1415610862,RESOLVE,,,
Mon Nov 10 10:14:22 2014 Attempting to establish TCP connection with [AF_INET]127.0.0.1:8080
Mon Nov 10 10:14:22 2014 MANAGEMENT: >STATE:1415610862,TCP_CONNECT,,,
Mon Nov 10 10:14:22 2014 TCP connection established with [AF_INET]127.0.0.1:8080
Mon Nov 10 10:14:22 2014 TCPv4_CLIENT link local: [undef]
Mon Nov 10 10:14:22 2014 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:8080
Mon Nov 10 10:14:22 2014 MANAGEMENT: >STATE:1415610862,WAIT,,,
Mon Nov 10 10:14:22 2014 MANAGEMENT: >STATE:1415610862,AUTH,,,
Mon Nov 10 10:14:22 2014 TLS: Initial packet from [AF_INET]127.0.0.1:8080, sid=a402be68 0218fd5f
Mon Nov 10 10:14:24 2014 VERIFY OK: depth=1, C=*, ST=*, L=*, O=*, OU=*, CN=ca, emailAddress=*
Mon Nov 10 10:14:24 2014 VERIFY OK: nsCertType=SERVER
Mon Nov 10 10:14:24 2014 VERIFY OK: depth=0, C=DE, ST=*, O=*, OU=*, CN=fritzbox, emailAddress=*
Mon Nov 10 10:14:26 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Nov 10 10:14:26 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 10 10:14:26 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Nov 10 10:14:26 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 10 10:14:26 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mon Nov 10 10:14:26 2014 [fritzbox] Peer Connection Initiated with [AF_INET]127.0.0.1:8080
Mon Nov 10 10:14:27 2014 MANAGEMENT: >STATE:1415610867,GET_CONFIG,,,
Mon Nov 10 10:14:28 2014 SENT CONTROL [fritzbox]: 'PUSH_REQUEST' (status=1)
Mon Nov 10 10:14:28 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.1.1,route 192.168.1.0 255.255.255.0,route 192.168.1.0 255.255.255.0,redirect-gateway,ping 10,ping-restart 120,ifconfig 192.168.1.100 255.255.255.0'
Mon Nov 10 10:14:28 2014 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov 10 10:14:28 2014 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov 10 10:14:28 2014 OPTIONS IMPORT: route options modified
Mon Nov 10 10:14:28 2014 OPTIONS IMPORT: route-related options modified
Mon Nov 10 10:14:28 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Nov 10 10:14:28 2014 MANAGEMENT: >STATE:1415610868,ASSIGN_IP,,192.168.1.100,
Mon Nov 10 10:14:28 2014 open_tun, tt->ipv6=0
Mon Nov 10 10:14:28 2014 TAP-WIN32 device [VPN] opened: \\.\Global\{174F1F12-8BEB-4452-868F-EDCD63A68F86}.tap
Mon Nov 10 10:14:28 2014 TAP-Windows Driver Version 9.9 
Mon Nov 10 10:14:28 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.1.100/255.255.255.0 on interface {174F1F12-8BEB-4452-868F-EDCD63A68F86} [DHCP-serv: 192.168.1.0, lease-time: 31536000]
Mon Nov 10 10:14:28 2014 Successful ARP Flush on interface [2] {174F1F12-8BEB-4452-868F-EDCD63A68F86}
Mon Nov 10 10:14:33 2014 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
Mon Nov 10 10:14:33 2014 C:\WINDOWS\system32\route.exe ADD 127.0.0.1 MASK 255.255.255.255 *.*.*.1
Mon Nov 10 10:14:33 2014 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter.   [status=87 if_index=3]
Mon Nov 10 10:14:33 2014 Route addition via IPAPI failed [adaptive]
Mon Nov 10 10:14:33 2014 Route addition fallback to route.exe
Mon Nov 10 10:14:33 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Mon Nov 10 10:14:33 2014 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 *.*.*.1
Mon Nov 10 10:14:33 2014 Route deletion via IPAPI succeeded [adaptive]
Mon Nov 10 10:14:33 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.1.1
Mon Nov 10 10:14:33 2014 Route addition via IPAPI succeeded [adaptive]
Mon Nov 10 10:14:33 2014 MANAGEMENT: >STATE:1415610873,ADD_ROUTES,,,
Mon Nov 10 10:14:33 2014 C:\WINDOWS\system32\route.exe ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.1
Mon Nov 10 10:14:33 2014 Route addition via IPAPI succeeded [adaptive]
Mon Nov 10 10:14:33 2014 C:\WINDOWS\system32\route.exe ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.1
Mon Nov 10 10:14:33 2014 Route addition via IPAPI succeeded [adaptive]
Mon Nov 10 10:14:33 2014 Initialization Sequence Completed
Mon Nov 10 10:14:33 2014 MANAGEMENT: >STATE:1415610873,CONNECTED,SUCCESS,192.168.1.100,127.0.0.1
Mon Nov 10 10:15:09 2014 Connection reset, restarting [0]
Mon Nov 10 10:15:09 2014 SIGUSR1[soft,connection-reset] received, process restarting
Mon Nov 10 10:15:09 2014 MANAGEMENT: >STATE:1415610909,RECONNECTING,connection-reset,,
Mon Nov 10 10:15:09 2014 Restart pause, 5 second(s)
Mon Nov 10 10:15:14 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 10 10:15:14 2014 MANAGEMENT: >STATE:1415610914,RESOLVE,,,
Mon Nov 10 10:15:14 2014 Attempting to establish TCP connection with [AF_INET]127.0.0.1:8080
Mon Nov 10 10:15:14 2014 MANAGEMENT: >STATE:1415610914,TCP_CONNECT,,,
Mon Nov 10 10:15:15 2014 TCP: connect to [AF_INET]127.0.0.1:8080 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)
Mon Nov 10 10:15:20 2014 MANAGEMENT: >STATE:1415610920,RESOLVE,,,
Mon Nov 10 10:15:20 2014 MANAGEMENT: >STATE:1415610920,TCP_CONNECT,,,
Mon Nov 10 10:15:21 2014 TCP: connect to [AF_INET]127.0.0.1:8080 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)
Mon Nov 10 10:15:26 2014 MANAGEMENT: >STATE:1415610926,RESOLVE,,,
Mon Nov 10 10:15:26 2014 MANAGEMENT: >STATE:1415610926,TCP_CONNECT,,,
Mon Nov 10 10:15:27 2014 TCP: connect to [AF_INET]127.0.0.1:8080 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)
Mon Nov 10 10:15:32 2014 MANAGEMENT: >STATE:1415610932,RESOLVE,,,
Mon Nov 10 10:15:32 2014 MANAGEMENT: >STATE:1415610932,TCP_CONNECT,,,
Mon Nov 10 10:15:33 2014 TCP: connect to [AF_INET]127.0.0.1:8080 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)
Mon Nov 10 10:15:35 2014 C:\WINDOWS\system32\route.exe DELETE 192.168.1.0 MASK 255.255.255.0 192.168.1.1
Mon Nov 10 10:15:35 2014 Route deletion via IPAPI succeeded [adaptive]
Mon Nov 10 10:15:35 2014 C:\WINDOWS\system32\route.exe DELETE 192.168.1.0 MASK 255.255.255.0 192.168.1.1
Mon Nov 10 10:15:35 2014 ROUTE: route deletion failed using DeleteIpForwardEntry: Falscher Parameter.  
Mon Nov 10 10:15:35 2014 Route deletion via IPAPI failed [adaptive]
Mon Nov 10 10:15:35 2014 Route deletion fallback to route.exe
Mon Nov 10 10:15:35 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Mon Nov 10 10:15:35 2014 C:\WINDOWS\system32\route.exe DELETE 127.0.0.1 MASK 255.255.255.255 134.99.189.1
Mon Nov 10 10:15:35 2014 ROUTE: route deletion failed using DeleteIpForwardEntry: Falscher Parameter.  
Mon Nov 10 10:15:35 2014 Route deletion via IPAPI failed [adaptive]
Mon Nov 10 10:15:35 2014 Route deletion fallback to route.exe
Mon Nov 10 10:15:35 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Mon Nov 10 10:15:35 2014 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.1.1
Mon Nov 10 10:15:35 2014 Route deletion via IPAPI succeeded [adaptive]
Mon Nov 10 10:15:35 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 134.99.189.1
Mon Nov 10 10:15:35 2014 Route addition via IPAPI succeeded [adaptive]
Mon Nov 10 10:15:35 2014 Closing TUN/TAP interface
Mon Nov 10 10:15:35 2014 SIGTERM[hard,init_instance] received, process exiting
Mon Nov 10 10:15:35 2014 MANAGEMENT: >STATE:1415610935,EXITING,init_instance,,

Ich vermute, daß evtl. etwas mit dem Routing und/oder einer Sicherheitsbeschränkung im Dropbear noch nicht stimmt ...
Wenn da noch jemand einen Tip für mich hätte, wäre das natürlich Spitze.
Grüße,

JD.

 

[RalfFriedl]

Was macht denn die SSH Verbindung zum letzten Server? Öffnet diese auch eine Shell, oder ein konkretes Kommando?
Normalerweise gibt es keinen Grund für den SSH Server, die Verbindung zu beenden, solange nicht das ausgeführte Kommando beendet ist.

 

[MaxMuster]

Kann es sein, dass du dir auf dem Client mit den VPN-Routen die SSH-Verbindung "zerschießt", indem du das nächste SSH-Ziel in den VPN-Tunnel routest?!?
Eine Host-Route zum "SSH next hop" muss außerhalb des VPNs "normal" geroutet werden...

 

[PeterPawn]

Ich vermute, daß evtl. etwas mit dem Routing

Die Vermutung kann man wohl nur unterstreichen.

Wenn das Standard-Gateway bei aufgebauter OpenVPN-Verbindung auf der FRITZ!Box als OpenVPN-Server liegen soll, weiß der SSH-Tunnel auch nicht mehr, wohin er seine Pakete schicken soll. Er sendet die dann an die 192.168.1.1 -> damit kommen die beim TAP-Device an, das diese Pakete dann in OpenVPN-Pakete verpackt und an den SSH-Tunnel schickt, der seinerseits die Pakete dann an die 192.168.1.1 als Standard-Gateway schickt ... fällt Dir auf, was an dieser Konstruktion nicht funktionieren kann ?
In dem Moment, wo das Route-Kommando

C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 a.b.c.d

das Standard-Gateway gelöscht hat, erreicht nicht ein einziges Paket des SSH-Tunnels mehr den nächsten Hop.

Wenn der OpenVPN-Server unbedingt das Push für das Gateway machen muß, mußt Du dem Client das Übernehmen dieser Angaben verbieten, es gibt eine Option, ich habe aber keine Lust, das jetzt rauszusuchen.

Abgesehen davon erscheint mir der Client auch etwas sehr merkwürdig konfiguriert. Ein Kommando wie

C:\WINDOWS\system32\route.exe ADD 127.0.0.1 MASK 255.255.255.255 a.b.c.d

kann ich aus den vom Server übertragenen Einstellungen nicht ableiten - abgesehen davon, daß das obige Anliegen ja überhaupt keinen Sinn macht.

Eine Route zu "localhost" über eine externe Adresse anlegen zu wollen ... da ist wohl ein lokal auszuführendes Skript nicht darauf eingestellt, daß das vom Client angesteuerte Tunnelende auf einmal die 127.0.0.1 mit dem SSH-Tunnel ist.

Das aktive Management-Interface mit "hold release" legt die Verwendung irgendeines GUI (und zwar nicht des mittlerweile "offiziellen" GUI von Sundman) nahe.

Aber das Kommando zum Hinzufügen der o.a. Route verstehe ich eigentlich auch in keinem Kontext so richtig ... wenn es nicht ein extra Gateway für den OpenVPN-Verkehr geben sollte, macht das ja auch mit einer anderen Konfiguration nur bedingt Sinn, wenn da steht "Schicke allen Verkehr an die öffentliche Adresse des OpenVPN-Servers über dieses spezielle Gateway und benutze dafür nicht das bekannte Standard-Gateway.". Das kann ich mir für ein echtes "multi-homed"-System mit mehreren WAN-Routen noch vorstellen, jenseits dessen eigentlich nicht mehr.

Wie auch immer ... Du darfst das Routing in Deinem Szenario so nicht übernehmen und wenn Du am Ende wirklich allen lokalen Verkehr durch den OpenVPN-Tunnel jagen willst, mußt Du zumindest für den SSH-Tunnel eine Ausnahme machen (s.o.). Ob das mit Windows-Bordmitteln so ohne weiteres funktioniert, will ich nicht per se bestreiten ... aber einfach wird diese Konfiguration keineswegs, selbst wenn sie möglich sein sollte.