Hi,
ich habe da ein etwas seltsames Problem, dass der SSL-Handshake verschiedener Dienste bei eingehenden IPv6-Verbindungen über ein VPN plötzlich nicht mehr funktioniert. Und zwar ziemlich genau seit dem 19.11.2013 um 07:55. Kurz funktioniert hat es wieder zwischen 20:00 und 22:40 am selben Tag. Seit dem geht gar nichts mehr. Die Problemserver sind alle jeweils als Client an einem anderen VPN-Server angemeldet.
Bisher betroffen sind der SSH und Munin-Node Daemon. HTTPS (über Nginx) zeigt keine Auffälligkeiten. Über IPv4 (auch im VPN) und über die öffentliche IP (IPv4/IPv6) konnte ich das Problem noch nicht reproduzieren, es ist rein auf IPv6-Verbindungen über das VPN beschränkt. Lustig ist auch, dass es ausschließlich meine drei KVM vServer bei netcup betrifft. Andere Systeme, die am selben OpenVPN-Server angemeldet sind und eine identische Konfiguration aufweisen, zeigen keine Probleme. Diese verwenden teilweise auch KVM-Virtualisierung. An den betroffenen Systemen wurde nichts verändert, auch Updates (die damit zusammen hängen könnten) wurden keine eingespielt.
Iptables wird überall verwendet, aber selbst ein Leeren aller Ketten und Zurücksetzen der Standardaktionen ändert nichts. Das bestehende Setup läuft seit Monaten problemlos. Hier ein kurzer Auszug des Paketmitschnitts:
# Der folgende Teil ist auf dem Client, Router, VPN- und Zielserver sichtbar:
20:57:37.841123 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [S], seq 2713835064, win 14400, options [mss 1440,sackOK,TS val 9921809 ecr 0,nop,wscale 7], length 0
20:57:37.905709 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [S.], seq 3714724416, ack 2713835065, win 14280, options [mss 1440,sackOK,TS val 3233247 ecr 9921809,nop,wscale 5], length 0
20:57:37.905795 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], ack 1, win 113, options [nop,nop,TS val 9921825 ecr 3233247], length 0
20:57:38.170369 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [P.], seq 1:33, ack 1, win 447, options [nop,nop,TS val 3233314 ecr 9921825], length 32
20:57:38.170704 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], ack 33, win 113, options [nop,nop,TS val 9921891 ecr 3233314], length 0
20:57:38.170961 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 1:33, ack 33, win 113, options [nop,nop,TS val 9921891 ecr 3233314], length 32
20:57:38.202829 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [.], ack 33, win 447, options [nop,nop,TS val 3233322 ecr 9921891], length 0
20:57:38.202894 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 33:1233, ack 33, win 113, options [nop,nop,TS val 9921899 ecr 3233322], length 1200
20:57:38.206522 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [P.], seq 33:1017, ack 33, win 447, options [nop,nop,TS val 3233322 ecr 9921891], length 984
20:57:38.260821 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], ack 1017, win 128, options [nop,nop,TS val 9921914 ecr 3233322], length 0
20:57:38.290331 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [.], ack 1233, win 536, options [nop,nop,TS val 3233343 ecr 9921899], length 0
20:57:38.290398 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 1233:1313, ack 1017, win 128, options [nop,nop,TS val 9921921 ecr 3233343], length 80
20:57:38.339555 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [P.], seq 1017:1329, ack 1313, win 536, options [nop,nop,TS val 3233356 ecr 9921921], length 312
20:57:38.339632 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], ack 1329, win 144, options [nop,nop,TS val 9921933 ecr 3233356], length 0
20:57:38.350369 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 1313:1329, ack 1329, win 144, options [nop,nop,TS val 9921936 ecr 3233356], length 16
20:57:38.414136 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [.], ack 1329, win 536, options [nop,nop,TS val 3233375 ecr 9921936], length 0
20:57:38.414206 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 1329:1377, ack 1329, win 144, options [nop,nop,TS val 9921952 ecr 3233375], length 48
20:57:38.445752 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [.], ack 1377, win 536, options [nop,nop,TS val 3233382 ecr 9921952], length 0
20:57:38.446017 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [P.], seq 1329:1377, ack 1377, win 536, options [nop,nop,TS val 3233382 ecr 9921952], length 48
20:57:38.448218 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 1377:1441, ack 1377, win 144, options [nop,nop,TS val 9921960 ecr 3233382], length 64
20:57:38.481822 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [P.], seq 1377:1489, ack 1441, win 536, options [nop,nop,TS val 3233391 ecr 9921960], length 112
# Der nachfolgende Teil ist komischerweise nur noch am Client, Router und VPN-Server sichtbar, aber nicht mehr am Zielserver:
20:57:38.536810 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], ack 1489, win 144, options [nop,nop,TS val 9921983 ecr 3233391], length 0
20:57:41.076947 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9922618 ecr 3233391], length 1428
20:57:41.076999 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [P.], seq 2869:3169, ack 1489, win 144, options [nop,nop,TS val 9922618 ecr 3233391], length 300
20:57:41.137355 IP6 SERVERv6.22 > CLIENTv6.38747: Flags [.], ack 1441, win 536, options [nop,nop,TS val 3234055 ecr 9921983,nop,nop,sack 1 {2869:3169}], length 0
20:57:41.148868 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9922636 ecr 3234055], length 1428
20:57:41.404843 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9922700 ecr 3234055], length 1428
20:57:41.916823 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9922828 ecr 3234055], length 1428
20:57:42.944830 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9923085 ecr 3234055], length 1428
20:57:44.996821 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9923598 ecr 3234055], length 1428
20:57:49.100885 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9924624 ecr 3234055], length 1428
20:57:57.324859 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9926680 ecr 3234055], length 1428
20:58:13.740836 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9930784 ecr 3234055], length 1428
20:58:46.636828 IP6 CLIENTv6.38747 > SERVERv6.22: Flags [.], seq 1441:2869, ack 1489, win 144, options [nop,nop,TS val 9939008 ecr 3234055], length 1428SSH zeigt im Debugmodus (auf Client und Serverseite) leider überhaupt nichts, sobald der Publickey gesendet werden sollte:
# /usr/sbin/sshd -Dddde
[…]
debug1: userauth_send_banner: sent [preauth]
debug2: input_userauth_request: try method none [preauth]
# ssh -v -6 xxx
[…]
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'xxx':
debug1: read PEM private key done: type DSA
Connection closed by SERVERv6 # oder manchmal auch…
Connection to SERVERv6 timed out while waiting to readMunin zeigt auf Clientseite nur folgendes:
[TLS] Warning in write: 28835: 1 - error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure
…was allerdings auch nur so viel wie "Da kam nichts zurück – Timeout!" bedeuten dürfte.
Bei den Serversystemen handelt es sich überall um Debian Wheezy, teilweise mit Distributionskernel, einmal mit eigenem.
Auf der Clientseite kam Xubuntu 13.04 und Debian Wheezy zum Einsatz. Beides jeweils mit dem Standarddistributionskernel.
Rein theoretisch könnte auch der VPN-Server schuld sein, allerdings müsste es doch dann bei allen VPN-Clients auftreten?
Vom Gefühl her sieht es fast so aus, als ob die entsprechenden UDP-Pakete von OpenVPN einfach im Nirvana landen, aber das kann es ja auch nicht sein 
Der Workaround ist im Moment, auf IPv6 im VPN zu verzichten und alle Clients nur auf die IPv4-Adressen verbinden zu lassen.
Da mir gerade nichts mehr einfällt, wie man dieses Problem weiter eingrenzen könnte, hoffe ich auf ein paar Tipps von euch.
MfG Christian
