openvpn problem mit tls authentication

rene04 · Beitrag von **rene04** » 21.10.2007 10:54:48

hallo,

ich habe mir zu hause nen openvpn server installiert und eingerichtet. dabei bin ich nach folgendem tutorial vorgegangen:

http://www.openvpn-forum.de/wiki/index.php/OVPN-Linux

leidere bekomme ich wenn ich mich als client versuche zu connecten folgenden fehler (die letzten beiden zeilen):

Code: Alles auswählen

WorkStation:/etc/openvpn# openvpn --config /etc/openvpn/server.conf
Sun Oct 21 10:47:49 2007 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Jan 21 2007
Sun Oct 21 10:47:49 2007 Diffie-Hellman initialized with 2048 bit key
Sun Oct 21 10:47:49 2007 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Oct 21 10:47:49 2007 TUN/TAP device tap0 opened
Sun Oct 21 10:47:49 2007 /sbin/ifconfig tap0 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Sun Oct 21 10:47:49 2007 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Oct 21 10:47:49 2007 UDPv4 link local (bound): [undef]:1194
Sun Oct 21 10:47:49 2007 UDPv4 link remote: [undef]
Sun Oct 21 10:47:49 2007 MULTI: multi_init called, r=256 v=256
Sun Oct 21 10:47:49 2007 IFCONFIG POOL: base=10.8.0.2 size=253
Sun Oct 21 10:47:49 2007 IFCONFIG POOL LIST
Sun Oct 21 10:47:49 2007 Initialization Sequence Completed
Sun Oct 21 10:47:57 2007 MULTI: multi_create_instance called
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 Re-using SSL/TLS context
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 LZO compression initialized
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 Local Options hash (VER=V4): 'f7df56b8'
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 Expected Remote Options hash (VER=V4): 'd79ca330'
Sun Oct 21 10:47:57 2007 127.0.0.1:32814 TLS: Initial packet from 127.0.0.1:32814, sid=76a06840 29736b27
Sun Oct 21 10:47:59 2007 127.0.0.1:32814 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sun Oct 21 10:47:59 2007 127.0.0.1:32814 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sun Oct 21 10:47:59 2007 127.0.0.1:32814 TLS: new session incoming connection from 127.0.0.1:32814
Sun Oct 21 10:48:01 2007 127.0.0.1:32814 TLS: new session incoming connection from 127.0.0.1:32814
Sun Oct 21 10:48:57 2007 127.0.0.1:32814 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Oct 21 10:48:57 2007 127.0.0.1:32814 TLS Error: TLS handshake failed

anzumerken sei, dass ich alles auf der selben maschine teste. also ich starte den server und den client auf der selben maschine.

jemand ne idee an was es hängt? kann ich die configs erstmal so anpassen das es ohne zertifikate funktioniert? wenn ja wie? und benötige ich die zertifikate unbedingt?

gruesse

DynaBlaster · Beitrag von **DynaBlaster** » 21.10.2007 12:38:23

Bei mir kommt dieser Fehler immer, wenn ich mit meinem Client den OpenVPN-Server nicht erreichen kann. Das kommt in schöner Regelmässigkeit vor, wenn ich mal wieder vergessen habe, am DSL-Router das IDLE-Timeout abzuschalten und demnach nach 30 Min. mein Home-Server über seine DynDNS-Adresse natürlich nicht mehr erreicbar ist ...

Ich tippe also auf die Netzwerkverbindung - warum dieses Problem allerdings auftritt ist mir schleierhaft - die Kommunikation über das Loopback-Device müsste ja auf jeden Fall klappen.

Im Log steht als OpenVPN-Device tap0 - wenn du tun0 benutzt, also ein geroutetes und kein gebridgetes VPN aufbaust, kannst du mit statischen Keys (siehe OpenVPN-Homepage) arbeiten und auf Zertifikakate und TLS verzichten - ob das auch mit tap-Devices funktioniert, weiss ich nicht.

Zur weiteren Anlayse wären server.conf, client.conf und evtl. /etc/network/interfaces (wegen der Bridge) hilfreich.

rene04 · Beitrag von **rene04** » 21.10.2007 19:20:59

hi,

also lokal hab ich es nun hinbekommen. aber über die öffentliche ip des routers nicht. auf dem router habe ich für die ip meines servers eine portweiterleitung auf 1194 udp gemacht (speedport w 700v).

server.ovpn:

Code: Alles auswählen

# Port Standardport 1194
port 1194

# Die Revoke Liste überprüfen
#crl-verify /etc/ssl/crl.pem

# TCP oder UDP?
proto udp
mode server
tls-server

dev tap

#Unsere Server IP
ifconfig 192.168.2.100 255.255.255.0
ifconfig-pool 192.168.2.102 192.168.2.109
#Server IP Adresse (Adressbereich. in dem Fall alles von 10.10.10.0)
#server 

#Wo liegen unsere Zertifikate
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem

#Die Selbe IP in der nächsten Sitzung vergeben
#ifconfig-pool-persist ipp.txt

#IPs in den IP Tables eintragen, DNS neu vergeben und über Den Server das Routing machen, dass man z.B. über den Tunnel auf ein
# lokales Intranet zuzugreifen
#push "route 10.0.0.0 255.0.0.0"
#push "dhcp-option DNS 192.168.1.xyz"
#push "redirect-gateway"
#push "route 0.0.0.0 0.0.0.0"

#Authentifizierungsmethode
auth SHA1

#Verschlüsselungs Algorithmus
cipher aes-256-cbc

#Benutze Komprimierung
comp-lzo

#Setzt die Rechte
#user nobody
#group nogroup

#Wird wegen user nobody/group nobody benötigt.
persist-key
persist-tun

#Logging 0, (Zum testen:5)
verb 7

client-to-client

client.ovpn auf virtueller windows maschine über virtualbox):

Code: Alles auswählen

#Festlegen als was fungiert wird
tls-client
pull

# Methode festlegen tun oder tap
dev tap

# Protokoll auswaehlen udp oder tcp
proto udp

# IP/Name und Port des Servers
remote 84.166.199.71 1194

# Auflösen des Hostnames des Servers (wegen nicht permanent mit dem Internet verbundenen Rechnern)
resolv-retry infinite

# Lacalen Port festlegen oder freigeben
nobind

# Verbindung immer gleich halten
persist-key
persist-tun

#zu verwendende Zertifikate und Schlüssel
ca C:\\programme\\openvpn\\config\\ca.crt
cert C:\\programme\\openvpn\\config\\client1.crt
key C:\\programme\\openvpn\\config\\client1.key

# Verschlüsselung
cipher AES-256-CBC

# Komprimiernug
comp-lzo

# Authentifizierungsmethode
auth SHA1

# "Gesprächigkeit" des Tunnels
verb 3

# Silence repeating messages
mute 20

fehlermeldung des servers:

Code: Alles auswählen

Sun Oct 21 19:19:00 2007 us=337295 84.166.199.71:32950 Re-using SSL/TLS context
Sun Oct 21 19:19:00 2007 us=337381 84.166.199.71:32950 LZO compression initialized
Sun Oct 21 19:19:00 2007 us=337399 84.166.199.71:32950 MTU DYNAMIC mtu=0, flags=1, 0 -> 138
Sun Oct 21 19:19:00 2007 us=337423 84.166.199.71:32950 PID packet_id_init seq_backtrack=64 time_backtrack=15
Sun Oct 21 19:19:00 2007 us=337626 84.166.199.71:32950 PID packet_id_init seq_backtrack=64 time_backtrack=15
Sun Oct 21 19:19:00 2007 us=337643 84.166.199.71:32950 PID packet_id_init seq_backtrack=64 time_backtrack=15
Sun Oct 21 19:19:00 2007 us=337726 84.166.199.71:32950 PID packet_id_init seq_backtrack=64 time_backtrack=15
Sun Oct 21 19:19:00 2007 us=337751 84.166.199.71:32950 Control Channel MTU parms [ L:1590 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Oct 21 19:19:00 2007 us=337764 84.166.199.71:32950 MTU DYNAMIC mtu=1450, flags=2, 1590 -> 1450
Sun Oct 21 19:19:00 2007 us=337779 84.166.199.71:32950 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Oct 21 19:19:00 2007 us=337851 84.166.199.71:32950 Local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Sun Oct 21 19:19:00 2007 us=337865 84.166.199.71:32950 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Sun Oct 21 19:19:00 2007 us=356299 84.166.199.71:32950 Local Options hash (VER=V4): '1a6d5c5d'
Sun Oct 21 19:19:00 2007 us=356372 84.166.199.71:32950 Expected Remote Options hash (VER=V4): 'c6c7c21a'
Sun Oct 21 19:19:00 2007 us=356475 84.166.199.71:32950 GET INST BY REAL: 84.166.199.71:32950 [created]
Sun Oct 21 19:19:00 2007 us=356509 84.166.199.71:32950 UDPv4 READ [14] from 84.166.199.71:32950: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Sun Oct 21 19:19:00 2007 us=356537 84.166.199.71:32950 TLS: Initial packet from 84.166.199.71:32950, sid=7e5e3717 7b6efb84
Sun Oct 21 19:19:00 2007 us=356608 84.166.199.71:32950 UDPv4 WRITE [26] to 84.166.199.71:32950: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Sun Oct 21 19:19:00 2007 us=371246 GET INST BY REAL: 84.166.199.71:32950 [succeeded]
Sun Oct 21 19:19:00 2007 us=371740 84.166.199.71:32950 UDPv4 READ [22] from 84.166.199.71:32950: P_ACK_V1 kid=0 [ 0 ]
Sun Oct 21 19:19:00 2007 us=371975 GET INST BY REAL: 84.166.199.71:32950 [succeeded]
Sun Oct 21 19:19:00 2007 us=372141 84.166.199.71:32950 UDPv4 READ [114] from 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Sun Oct 21 19:19:00 2007 us=372370 84.166.199.71:32950 UDPv4 WRITE [22] to 84.166.199.71:32950: P_ACK_V1 kid=0 [ 1 ]
Sun Oct 21 19:19:00 2007 us=372696 GET INST BY REAL: 84.166.199.71:32950 [succeeded]
Sun Oct 21 19:19:00 2007 us=372987 84.166.199.71:32950 UDPv4 READ [16] from 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=2
Sun Oct 21 19:19:00 2007 us=401112 84.166.199.71:32950 UDPv4 WRITE [126] to 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ 2 ] pid=1 DATA len=100
Sun Oct 21 19:19:00 2007 us=401810 84.166.199.71:32950 UDPv4 WRITE [114] to 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Sun Oct 21 19:19:00 2007 us=402211 84.166.199.71:32950 UDPv4 WRITE [114] to 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Sun Oct 21 19:19:00 2007 us=402642 84.166.199.71:32950 UDPv4 WRITE [114] to 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Sun Oct 21 19:19:00 2007 us=403043 84.166.199.71:32950 ACK output sequence broken: [5] 1 2 3 4
Sun Oct 21 19:19:00 2007 us=409551 GET INST BY REAL: 84.166.199.71:32950 [succeeded]
Sun Oct 21 19:19:00 2007 us=409620 84.166.199.71:32950 UDPv4 READ [22] from 84.166.199.71:32950: P_ACK_V1 kid=0 [ 1 ]
Sun Oct 21 19:19:00 2007 us=409742 84.166.199.71:32950 UDPv4 WRITE [114] to 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Sun Oct 21 19:19:00 2007 us=409860 84.166.199.71:32950 ACK output sequence broken: [6] 5 2 3 4
Sun Oct 21 19:19:00 2007 us=412457 GET INST BY REAL: 84.166.199.71:32950 [succeeded]
Sun Oct 21 19:19:00 2007 us=412527 84.166.199.71:32950 UDPv4 READ [22] from 84.166.199.71:32950: P_ACK_V1 kid=0 [ 2 ]
Sun Oct 21 19:19:00 2007 us=412650 84.166.199.71:32950 UDPv4 WRITE [114] to 84.166.199.71:32950: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Sun Oct 21 19:19:00 2007 us=412764 84.166.199.71:32950 ACK output sequence broken: [7] 5 6 3 4

gruesse

DynaBlaster · Beitrag von **DynaBlaster** » 22.10.2007 14:25:56

Hm, läuft auf dem OpenVPN-Server selbst evtl. noch eine iptables-Script, das die Anfrage von ausserhalb des LAN verwirft?

Bei mir sehen die Dateien auf dem Server so aus:

/etc/openvpn/server.conf

Code: Alles auswählen

# net
port 1194
proto udp
dev tap0

# zertifikate
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# config
server-bridge  192.168.0.10 255.255.255.0 192.168.0.30 192.168.0.40
ifconfig-pool-persist ipp_tap.txt
client-to-client
keepalive 10 120
comp-lzo
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
fragment 1500
status openvpn-status.log
verb 3

und der relevante Teil aus /etc/network/interfaces (nach dem Howto auf der OpenVPN-Homepage)

Code: Alles auswählen

# config for a bridged openvpn setup
auto br0
iface br0 inet static
        address 192.168.0.10
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        pre-up /sbin/ip link set eth0 up
        pre-up /usr/sbin/openvpn --mktun --dev tap0
        pre-up /sbin/ip link set tap0 up
        pre-up /usr/sbin/brctl addbr br0
        pre-up /usr/sbin/brctl addif br0 eth0
        pre-up /usr/sbin/brctl addif br0 tap0
       # diese Zeile musste bei mir sein, da die 3c59x-Karte sonst nur mit 10MBit/Half-Duplex läuft 
        post-up /usr/sbin/ethtool -s eth0 autoneg off speed 100 duplex full
        post-down /usr/sbin/brctl delbr br0
        post-down /sbin/ifconfig eth0 down

rene04 · Beitrag von **rene04** » 22.10.2007 14:33:52

Hm, läuft auf dem OpenVPN-Server selbst evtl. noch eine iptables-Script, das die Anfrage von ausserhalb des LAN verwirft?

nö. da läuft nix.

deine configs sind für bridging konzipiert, ich nutze allerdings routing.

gruesse

DynaBlaster · Beitrag von **DynaBlaster** » 23.10.2007 00:04:25

Ich weiss, dass meine Configs für Bridging sind - ich dachte, du würdest auch eine Bridge wollen, weil du das hier in deiner Config hast:

Code: Alles auswählen

dev tap

Für ein geroutetes VPN sollte aber tun verwendet werden ...

rene04 · Beitrag von **rene04** » 23.10.2007 09:06:19

aha, das wusste ich nicht. da werd ich das mal umstellen auf tun.

leider ist mir die technik hinter bridging gänzlich unbekannt. was muss ich genau einstellen wenn der server hinter nem router hängt? is das wurscht ob ich tun oder tap nehme?

gruesse

DynaBlaster · Beitrag von **DynaBlaster** » 23.10.2007 10:48:48

Naja, der Unterschied zwischen einer Bridge und einem zusätzlichen Netzwerkdevice (also z.B. tun0) besteht in der Trennung des VPN vom "normalen" LAN. Die Bridge ist im Grunde nur nötig, weil z.B. Broadcast-Anfragen im Normalfall nicht geroutet werden - das hat zur Folge, dass einige Anwendungen und Computerspiele (z.B. Starcraft und Warcraft III) im LAN-Modus mit OpenVPN nicht funktionieren.
Im Normalfall ist also ein geroutetes OpenVPN ausreichend, wenn nicht sogar vorteilhafter.

Das alles dürfte aber keinen Unterschied für den Verbindungsaufbau zwischen OpenVPN-Client und OpenVPN-Server machen. Der wird schließlich über die "physikalischen" Netzwerkadapter hergestellt.

Ob die Fehlerquelle nun irgendwo in der Netzwerkinfrastruktur, dem Port-Forwarding usw.. hängt oder an der Konfiguration von OpenVPN, würde ich als nächstes testen, ob OpenVPN mit statischen Keys funktioniert - nur um die Zertifikate als Fehlerquelle auszuschließen. Siehe dazu: http://openvpn.net/static.html

rene04 · Beitrag von **rene04** » 23.10.2007 11:20:09

das werde ich am weekend gleich mal ausprobieren.

gruesse