ubuntuusers.de

Hallo zusammen, ich habe folgendes Problem:

Ich habe eine funktionierende OpenVPN Konfiguration. Ich kann mich damit (sollte mein Testrechner direkt am Server angeschlossen sein) mit dem VPN verbinden bzw. einen Tunnel aufbauen. Das Problem liegt abber bei der Verbindung über einen anderen Server der später das Gateway darstellen soll.

Die Konfigurations ist wie folgt:

Ein Testrechner mit einer öffentlichen IP-Adresse wird an einen Server1 mit ebenfalls einer öffentlichen IP-Adresse angeschlossen. Der Openvpn-Server ist über einen anderen Port mit Server1 verbunden. An diesem Port hat Server 1 die IP: 192.168.11.2/24 und der OpenVPN-Server die 192.168.11.1/24.

Nun setze ich noch eine route "sudo route add -net 192.168.11.0 netmask 255.255.255.0 gw ip_des-Server1 eth0 auf den Testrechner.

Nun kann ich zwar die 192.168.11.2 pingen (Adresse des Server1), aber nicht die 192.168.11.1 von dem OpenVPN-Server.

Der Logdatei eintragt, sagt nicht, außer das es einen TLS-Error gabe, ich weiß aber nicht wie dieser Fehler zu stande kommt, weil ja die Zertifikate bei Direktverbindung funktionieren.

Der Server1 kann den OpenVPN-Server pingen und umgekehrt, der Testrechner kann nur Server 1 pingen.

Log-Datei

Aug 21 11:16:26  ovpn-client[3404]: last message repeated 2 times
Aug 21 11:16:26 testrechner-ThinkPad-T510 ovpn-client[3404]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivit$
Aug 21 11:16:26 testrechner-ThinkPad-T510 ovpn-client[3404]: TLS Error: TLS handshake failed
Aug 21 11:16:26 testrechner-ThinkPad-T510 ovpn-client[3404]: TCP/UDP: Closing socket
Aug 21 11:16:26 testrechner-ThinkPad-T510 ovpn-client[3404]: SIGUSR1[soft,tls-error] received, process restarting
Aug 21 11:16:26 testrechner-ThinkPad-T510 ovpn-client[3404]: Restart pause, 2 second(s)
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: NOTE: the current --script-security setting may allow this configuration to call user-defined sc$
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: Re-using SSL/TLS context
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: LZO compression initialized
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: Socket Buffers: R=[229376->131072] S=[229376->131072]
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: Local Options hash (VER=V4): '41690919'
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: Expected Remote Options hash (VER=V4): '530fdded'
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: UDPv4 link local: [undef]
Aug 21 11:16:28 testrechner-ThinkPad-T510 ovpn-client[3404]: UDPv4 link remote: [AF_INET]192.168.11.1:1194

Weiß einer von euch wo das Problem liegt?

Danke schonmal für eure Hilfe.

MfG Twinhand

Und Server1 ist auch so eingestellt, dass er ein Routing betreibt, mit dem er die Pakete für den OpenVPN-Server auch weiter leitet? Siehe dazu auch Router

Zumindest wenn Shorewall aktiv ist, ist ein NAT eingerichtet, das die Pakete weiterleiten soll. Hat aber weder bei Aktiver Firewall noch bei deaktivierter Firewall funktioniert (Die Firewall selbst dürfte nichts in die Richtung blocken).

#OpenVPN Port-Forward
DNAT    net:öffentliche IP      loc:192.168.11.2        udp     1194
DNAT    net:öffentliche IP      loc:192.168.11.2        udp     500
DNAT    net:öffentliche IP      loc:192.168.11.2        udp     4500

Wenn dein Server1 NAT macht, dann musst du auch deine OpenVPN-Verbindung zu Server1 aufbauen, und nicht zum OpenVPN-Server. Wenn das NAT richtig konfiguriert ist, leitet Server1 das dann an den OpenVPN-Server weiter.

Hallo Lookbehind,

danke für die Antwort habe genau das versucht, was du mir geraten hast.

Es passiert nun folgendes:

Die Firewall blockiert den Verkehr nicht(zumindest laut Log-Dateien)

Der Client gibt nach wie vor die Meldung (111 connection refused) ab.

Auf dem Open-VPN-Server sind keinerlei Logeinträge im Bezug auf OpenVPN zu finden. Der Server ist jedoch aktiv.

Log Server 1

Aug 25 13:35:06 gwfw kernel: [ 1073.109707] Shorewall:dmz2fw:ACCEPT:IN=br0 OUT= PHYSIN=eth0 MAC=84:2b:2b:5d:72:dc:f0:de:f1:45:66:c2:08:00 SRC=ÖFFENTLICHE-IP-SERVER1 DST=ÖFFENTLICHE-IP-OPENVPN-SERVER LEN=42 TOS=0x00 PREC=0x00 TTL=64 ID=55357 DF PROTO=UDP SPT=33948 DPT=1194 LEN=22
Aug 25 13:35:14 gwfw kernel: [ 1081.264897] Shorewall:dmz2fw:ACCEPT:IN=br0 OUT= PHYSIN=eth0 MAC=84:2b:2b:5d:72:dc:f0:de:f1:45:66:c2:08:00 SRC=ÖFFENTLICHE-IP-SERVER1 DST=ÖFFENTLICHE-IP-OPENVPN-SERVER LEN=42 TOS=0x00 PREC=0x00 TTL=64 ID=55358 DF PROTO=UDP SPT=33948 DPT=1194 LEN=22

DNAT

#OpenVPN Port-Forward
DNAT    dmz:ÖFFENTLICHE-IP-SERVER1      loc:192.168.11.1        udp     1194
DNAT    dmz:ÖFFENTLICHE-IP-SERVER1      loc:192.168.11.1        udp     500
DNAT    dmz:ÖFFENTLICHE-IP-SERVER1      loc:192.168.11.1        udp     4500

Log-Client

Aug 25 13:32:57 testrechner-ThinkPad-T510 ovpn-client[4628]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivit$
Aug 25 13:32:57 testrechner-ThinkPad-T510 ovpn-client[4628]: TLS Error: TLS handshake failed
Aug 25 13:32:57 testrechner-ThinkPad-T510 ovpn-client[4628]: TCP/UDP: Closing socket
Aug 25 13:32:57 testrechner-ThinkPad-T510 ovpn-client[4628]: SIGUSR1[soft,tls-error] received, process restarting
Aug 25 13:32:57 testrechner-ThinkPad-T510 ovpn-client[4628]: Restart pause, 2 second(s)
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: NOTE: the current --script-security setting may allow this configuration to call user-defined sc$
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: Re-using SSL/TLS context
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: LZO compression initialized
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: Socket Buffers: R=[229376->131072] S=[229376->131072]
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: Local Options hash (VER=V4): '41690919'
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: Expected Remote Options hash (VER=V4): '530fdded'
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: UDPv4 link local: [undef]
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: UDPv4 link remote: [AF_INET]ÖFFENTLICHE-IP-Server1:1194
Aug 25 13:32:59 testrechner-ThinkPad-T510 ovpn-client[4628]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

MfG Twinhand

Und das NAT funktioniert so auch? Hast du das mal mit einem anderen Port und simpleren Protokoll (gegebenenfalls kann man netcat für sowas verwenden) getestet?

Wie genau geht das denn mit netcad von statten?

Du machst auf dem OpenVPN-Server mit

nc -l <PORT>

einen Port auf, und versuchst dem Client per

nc <PUBLIC-GATEWAY-IP> <PORT>

darauf zu verbinden. Wenn das klappt, hast du einen simplen Chat erreicht. Was du auf der einen Konsole eingibst, müsste auf der Konsole des anderen erscheinen.

Für weiteres siehe

man netcat

Netcat kann ja letztlich noch einiges mehr als das. Ist auch bekannt als das Schweizer Armeemesser unter den Netzwerk-Tools.

Leider hat der Test nicht funktioniert. Ich habe aber keinen Anhaltspunkt woran das liegen könnte. Die DNAT-Konfiguration ist genau so wie in den Beispielen des Shorewall-Dokumentation beschrieben. Vor jeden Test trenne ich die Server vom restlichen Netz, damit keine anderen Firewalls einfluss nehmen können etc.

Gibt es Ideen, wo ich eine Antwort finde?

MfG Twinhand

Nachtrag*

Der Befehl "shorewall show nat" gibt utner anderen folgendes aus. Was so viel heißt wie, das die Pakte nicht am Zielort ankommen.

Chain net_dnat (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            ÖFFENTLICHE-IP-SERVER1       udp dpt:1194 to:192.168.11.1
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            ÖFFENTLICHE-IP-SERVER1        udp dpt:500 to:192.168.11.1
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            ÖFFENTLICHE-IP-SERVER1        udp dpt:4500 to:192.168.11.1

Also habe ich sicherheitshalber die DNAT-Konfiguration um die "Original Destination" erweitert (wie es auf der Shorewall-Seite vorgeschlagen wird) leider gibt es keine Veränderung.

DNAT   net      loc:192.168.11.1        udp     1194    -       ÖFFENTLICHE-IP-SERVER1
DNAT   net      loc:192.168.11.1        udp     500     -       ÖFFENTLICHE-IP-SERVER1
DNAT   net      loc:192.168.11.1        udp     4500    -       ÖFFENTLICHE-IP-SERVER1

Edit/Bump

Das Interface über das ich Server1 Anspreche ist ein Bridge Interface (br0). (Falls das irgendeinen Einfluss hat.)

Edit2:

Ich habe echt keine Ideen mehr, es kein auch kein Problem mit dem Service-Provider sein, da beim Test die Server von der restlichen Welt getrennt sind.

Fehlermeldungen sind nicht vorhanden. Der Befehl shorewall show nat sagt aber auch, das die Weiterleitung nicht funktioniert.

Edit3:

Nach vielen Tests ist folgender Sachverhalt klar geworden (die Ursache nach wie vor, nicht). Das Paket wird anscheinend dupliziert und eine Variante des Pakets wird passend umgeschrieben. Jedoch verlässt das Paket, aus ungekläreten Gründen nicht die Firewall.

*Bump

10:54:17.012512 IP ÖFFENTLICHE-IP_TESTRECHNER.44678 > ÖFFENTLICHE-IP-OPENVPNSERVER.openvpn: UDP, length 14
10:54:17.012547 IP ÖFFENTLICHE-IP_TESTRECHNER.44678 > 192.168.11.1.openvpn: UDP, length 14
10:54:17.012613 IP 130.83.165.129 > 1ÖFFENTLICHE-IP_TESTRECHNER: ICMP ÖFFENTLICHE-IP-OPENVPNSERVER udp port openvpn unreachable, length 50
10:54:17.012618 IP 130.83.165.129 > ÖFFENTLICHE-IP_TESTRECHNER: ICMP ÖFFENTLICHE-IP-OPENVPNSERVER udp port openvpn unreachable, length 50

Hat irgendwer eine Idee? Ich verstehe einfach nicht, warum er das macht.

MfG Twinhand

Langsam wird es witzlos. Ich habe Testweise die Rules Datei verschoben und in der Policys Datei ALLES erlaubt. Jetzt wird nichtsmehr geblockt, aber ich kann bei aktiver Firewall trotzdem noch nichtmal einen Ping an den OpenVPN-Server absetzen. Mit deaktivierter Firewall schon.

Gibt es wirklich niemanden der irgendeine Idee hat?

MfG Twinhand

Update:

Aufgrund eines Fehler bei den Parametern in der Interface-Datei der Firewall, wurde das Paket nicht korrekt umgeschrieben. Der Fehler ist jetzt behoben und das Paket wird passend umgeschrieben.

Tcpdump Server 1 bei versuchten Aufbau eines VPNs.

09:45:07.734537 IP ÖFFENTLICHE-IP-TESTRECHNER.37254 > 1ÖFFENTLICHE-IP-SERVER1.openvpn: UDP, length 14
09:45:07.734569 IP ÖFFENTLICHE-IP-TESTRECHNER.37254 > 192.168.11.1.openvpn: UDP, length 14
09:45:07.734587 IP ÖFFENTLICHE-IP-TESTRECHNER.37254 > 192.168.11.1.openvpn: UDP, length 14

Tcpdump OpenVPN-SERVER bei versuchten Aufbau eines VPNs

09:59:02.263280 IP ÖFFENTLICHE-IP-TESTRECHNER.41559 > 192.168.11.1.openvpn: UDP, length 14
09:59:10.472918 IP ÖFFENTLICHE-IP-TESTRECHNER.41559 > 192.168.11.1.openvpn: UDP, length 14
09:59:26.712577 IP ÖFFENTLICHE-IP-TESTRECHNER.41559 > 192.168.11.1.openvpn: UDP, length 14

(Auf die Zeit muss nicht geachtet werden, die beiden Dateien wurden bei unterschiedlichen Tests erstellt.)

Die Pakete kommen an dem OpenVPN-Server an, aber es gibt keine Rückmeldung (zumindest konnte diese nicht aufgezeichnet werden). In den Log-Dateien des OpenVPN-Servers befinden sich keine Hinweise.

Hat jemand eine Idee wo das Problem liegen könnte?

MfG Twinhand