[Gelöst] openvpn: Tunnel steht, kein ping

[Ohrenschmalz]

Moinsen,
ich hätt da gern mal nen Problem...

Situation: openvpn Server in der Firma (Linux)
Meine Fritte als Client eingerichtet. Tun mit Zertifikaten.

Zertifikate eingespielt, eingerichtet, alles schick. Tunnel steht, ich kriege per push Routen und IPs announced, Certs auch alles ok...

Leider, leider kann ich beidseitig nicht pingen...
tcpdump auf dem Server zeigt abgehende ICMP-Pakete in meine Richtung, tcpdump auf tun0 meiner Box zeigt auch abgehende ICMP-Pakete in Richtung Firma...allein, es kommt nirgends was an...hab die dörrige AVM-Firewall im Verdacht...

Wer kann mir mal auf die Sprünge helfen? Braucht ihr logs oder ähnliches?

Bin für jede Hilfe dankbar...

Danke!

 

[olistudent]

Logs sind natürlich immer gut. Kennst du http://freetz.org/wiki/packages/openvpn?

Gruß
Oliver

 

[Ohrenschmalz]

Jau, kenn ich...gut. Hab die Conf entsprechend meiner Box angepasst. Bis auf ping tut ja alles...
Ich muß jetzt erstmal paar Stromkabel inner Wand verlegen und poste heute nachmittag meine Logs...muß nur einiges bereinigen daraus...

Bis später

 

[MaxMuster]

Besonders interessant wäre die Frage, von wo das versucht wurde. Von der Box oder vom Pc dahinter?
Grundsätzlich wird die Firewall nicht beim Tunnel eingreifen, die arbeitet nur auf dem DSL.

 

[Ohrenschmalz]

Moinsen,
hat nu doch bissl länger gedauert...

Alle Versuche habe ich von der Box aus gemacht...
Ich poste mal nen paar Sachen; natürlich bereinigt...hoffe das reicht so:

root@fritz:/var/mod/root# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.xx   *               255.255.255.255 UH    2      0        0 dsl
yy.yy.0.33     *               255.255.255.255 UH    0      0        0 tun0
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
yy.yy.0.1      yy.yy.0.33     255.255.255.255 UGH   0      0        0 tun0
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
xx.xx.xx.xx    *               255.255.255.255 UH    3      0        0 dsl
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
192.168.1.0     *               255.255.255.0   U     0      0        0 lan
192.168.222.0   yy.yy.0.33     255.255.255.0   UG    0      0        0 tun0
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

root@fritz:/var/mod/root# ip r
xx.xx.xx.xx dev dsl  metric 2 
yy.yy.0.33 dev tun0  src yy.yy.0.34 
192.168.180.1 dev dsl  metric 2 
yy.yy.0.1 via yy.yy.0.33 dev tun0 
192.168.180.2 dev dsl  metric 2 
xx.xx.xx.xx dev dsl  metric 3 
192.168.179.0/24 dev guest  src 192.168.179.1 
192.168.1.0/24 dev lan  src 192.168.1.1 
192.168.222.0/24 via yy.yy.0.33 dev tun0 
169.254.0.0/16 dev lan  src 169.254.1.1 
default dev dsl  metric 2

May 29 07:39:24 fritz daemon.notice openvpn[12748]: Restart pause, 2 second(s)
May 29 07:39:26 fritz daemon.warn openvpn[12748]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
May 29 07:39:26 fritz daemon.notice openvpn[12748]: Re-using SSL/TLS context
May 29 07:39:26 fritz daemon.notice openvpn[12748]: LZO compression initialized
May 29 07:39:26 fritz daemon.notice openvpn[12748]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
May 29 07:39:26 fritz daemon.notice openvpn[12748]: Socket Buffers: R=[108544->131072] S=[108544->131072]
May 29 07:39:26 fritz daemon.notice openvpn[12748]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
May 29 07:39:26 fritz daemon.notice openvpn[12748]: UDPv4 link local: [undef]
May 29 07:39:26 fritz daemon.notice openvpn[12748]: UDPv4 link remote: [AF_INET]zz.zz.zz.zz:1194
May 29 07:39:26 fritz daemon.notice openvpn[12748]: TLS: Initial packet from [AF_INET]zz.zz.zz.zz:1194, sid=46a0bbe4 18e37222
May 29 07:39:27 fritz daemon.notice openvpn[12748]: VERIFY OK: depth=1, Rest gesnipt
May 29 07:39:27 fritz daemon.notice openvpn[12748]: VERIFY OK: nsCertType=SERVER
May 29 07:39:27 fritz daemon.notice openvpn[12748]: VERIFY OK: depth=0, Rest gesnipt
May 29 07:39:27 fritz daemon.notice openvpn[12748]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
May 29 07:39:27 fritz daemon.notice openvpn[12748]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
May 29 07:39:27 fritz daemon.notice openvpn[12748]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
May 29 07:39:27 fritz daemon.notice openvpn[12748]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
May 29 07:39:27 fritz daemon.notice openvpn[12748]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
May 29 07:39:27 fritz daemon.notice openvpn[12748]: [server] Peer Connection Initiated with [AF_INET]zz.zz.zz.zz:1194
May 29 07:39:30 fritz daemon.notice openvpn[12748]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
May 29 07:39:30 fritz daemon.notice openvpn[12748]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.222.0 255.255.255.0,route yy.yy.0.1,topology net30,ping 10,ping-restart 120,ifconfig yy.yy.0.34 yy.yy.0.33'
May 29 07:39:30 fritz daemon.notice openvpn[12748]: OPTIONS IMPORT: timers and/or timeouts modified
May 29 07:39:30 fritz daemon.notice openvpn[12748]: OPTIONS IMPORT: --ifconfig/up options modified
May 29 07:39:30 fritz daemon.notice openvpn[12748]: OPTIONS IMPORT: route options modified
May 29 07:39:30 fritz daemon.notice openvpn[12748]: Preserving previous TUN/TAP instance: tun0
May 29 07:39:30 fritz daemon.notice openvpn[12748]: Initialization Sequence Completed

Hoffe, das war alles, was relevant sein könnte.

Oder braucht ihr mehr?

Danke schonmal!

 

[sf3978]

..., tcpdump auf tun0 meiner Box zeigt auch abgehende ICMP-Pakete in Richtung Firma...allein, es kommt nirgends was an...hab die dörrige AVM-Firewall im Verdacht...
...

Versuch mal ein Ping von der Box mit Angabe der Quelle.

 

[Ohrenschmalz]

Weder ping -I tun0 noch ping -I <IP> tun was...

Sehen denn die Logs soweit normal aus?
Danke!

 

[sf3978]

Weder ping -I tun0 noch ping -I <IP> tun was...
...

Versuch dann mal ein Ping von einem PC hinter der Box, auf den Server, mit Aufzeichnung der route (-R).

 

[Ohrenschmalz]

Nichts, nada, nothing...*kopfkratz*

Bin ratlos...

 

[MaxMuster]

"Bisher" sieht das gut aus, aber so viel Info ist es ja noch nicht ;-). Erste "Verdächtige" bei aufgebautem Tunnel ohne Pingerfolg sind
- nur auf einer Seite LZO
- Firewall auf der "angepingten" Seite

Was genau hast du denn versucht anzupingen?
Nur als Hinweis: Die angegebene "IP" des Servers in dieser Konstellation (hier die yy.yy.0.33 zur Client-IP yy.yy.0.34) wird in der Regel nicht existieren, sondern wird nur als "Routinghilfe" beim Client genutzt und "in echt" hat der Server vermutlich die yy.yy.0.1 .

Jörg

 

[Ohrenschmalz]

Erste "Verdächtige" bei aufgebautem Tunnel ohne Pingerfolg sind
- nur auf einer Seite LZO

Nur als Hinweis: Die angegebene "IP" des Servers in dieser Konstellation (hier die yy.yy.0.33 zur Client-IP yy.yy.0.34) wird in der Regel nicht existieren, sondern wird nur als "Routinghilfe" beim Client genutzt und "in echt" hat der Server vermutlich die yy.yy.0.1 .

Jörg

LZO war der entscheidene Hinweis! Ausgemacht, ping von der Box auf die .0.1...tut
Schade nur, das die logfiles auf beiden Seiten dazu keine Fehlermeldungen geworfen haben...egal, von der Box aus tuts nun

Danke

P.S. Von Rechnern hinter der Box allerdings nicht, ist aber nicht soooo wichtig, nur interessehalber...

 

[MaxMuster]

Schön ;-)
Wenn die Rechner "hinter" der Box den Server (und die Netze dort) nicht erreichen können, fehlt mit ziemlicher Sicherheit dort (also beim Server) eine Route für dein LAN zu der VPN-IP deines Clients. Woher sollte der Server sonst wissen, dass er 192.168.1.0 zu yy.yy.0.34 schicken soll.
Entweder der Server bekommt diese Info noch (d.h. du musst den Admin dort zumindest beeinflussen können) oder aber du muss dein Netz hinter der VPN-IP "verstecken" (mittels iptables).

Jörg