[gelöst] OpenVPN Verbindungsproblem wegen ipv6

[am2]

Ich nutze schon seit einiger Zeit CyberGhost-VPN und bin damit zufrieden. Nun ist folgendes passiert...
Vorgestern lief alles wunderbar, gestern war der Rechner aus und heute keine Verbindung. Die üblichen Maßnahmen (Neustart von openvpn) brachten nichts. Mein Log sieht allerdings so aus:

Code: Alles auswählen

Dec  3 12:46:01 myhost ovpn-CG_DE[4908]: ROUTE6: default_gateway=UNDEF
Dec  3 12:46:01 myhost ovpn-CG_DE[4908]: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Dec  3 12:46:01 myhost ovpn-CG_DE[4908]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/3

Der Support von CyberGhost sagte mir, dass es an der ipv6-Geschichte liegt weil sie noch nicht unterstützt wird. Gut, dann liegt der Fehler eben auf meiner Seite.
Die ROUTE6-Einträge tauchten heute zum ersten Mal auf, die gab es vorher nicht. Logs vom 1. Dezember oder früher haben diese Einträge nicht. Wie kann ich dem "Übeltäter" auf die schliche kommen? ipv6 ist bei mir übrigens in der sysctl-conf mit net.ipv6.conf.all.disable_ipv6=1 deaktiviert.

[unitra]

Veruche mal die Schnittstellen explizit mit dem Namen zu konfigurieren z.B. eth0, wlan0

Code: Alles auswählen

net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.wlan0.disable_ipv6 = 1

Catchall .all.disable. hat manchmal Macken.

Ich nutze schon seit einiger Zeit CyberGhost-VPN und bin damit zufrieden. Nun ist folgendes passiert...
Vorgestern lief alles wunderbar, gestern war der Rechner aus und heute keine Verbindung. Die üblichen Maßnahmen (Neustart von openvpn) brachten nichts. Mein Log sieht allerdings so aus:

Code: Alles auswählen

Dec  3 12:46:01 myhost ovpn-CG_DE[4908]: ROUTE6: default_gateway=UNDEF
Dec  3 12:46:01 myhost ovpn-CG_DE[4908]: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Dec  3 12:46:01 myhost ovpn-CG_DE[4908]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/3

Der Support von CyberGhost sagte mir, dass es an der ipv6-Geschichte liegt weil sie noch nicht unterstützt wird. Gut, dann liegt der Fehler eben auf meiner Seite.
Die ROUTE6-Einträge tauchten heute zum ersten Mal auf, die gab es vorher nicht. Logs vom 1. Dezember oder früher haben diese Einträge nicht. Wie kann ich dem "Übeltäter" auf die schliche kommen? ipv6 ist bei mir übrigens in der sysctl-conf mit net.ipv6.conf.all.disable_ipv6=1 deaktiviert.

[am2]

Es gab viele Wege ipv6 zu deaktivieren, die ich im Netz gefunden habe. Deine Option habe ich ausprobiert, leider ohne Erfolg. Diese ROUTE6-Zeilen tauchen immer wieder auf (erst seit heute). Mein Laptop (beide laufen mit Debian Stretch) hat diese Probleme nicht. Es hat nur den Desktop-Rechner erwischt. Mir gehen langsam die Ideen aus. Auch die Deaktivierung von ipv6 über GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 in /etc/default/grub bringt nichts.

[wanne]

D steht in der OpenVPN-config irgend was von wegen IPv6 (und der Server kann aber kein IPv6.) das wird nicht besser davon dass du IPv6 noch mehr ausschaltest.
Eventuell willst du das trotzdem machen, weil IPv6 sonst weiter ohne VPN läuft.
Du hast das config-file (*.ovpn) von denen runter geladen?
Guck da mal rein. Da sind vermutlich irgend welche IPv6-Optionen drin. (Ich hoffe mal nicht, dass die ne IPv6 route von ihrem server pushen und es die dann nicht gibt.)
Eventuell wisst du das nochmal runter laden und hoffen dass es dieses mal richtig generiert wird oder schlicht und einfach mal das vom Laptop kopieren.
Alternativ kannst du da auch mal die Passwörter raus schmeißen und das mal hier posten.

[am2]

Hier ist die Config-Datei:

Code: Alles auswählen

client
remote 1-at.cg-dialup.net 443
dev tun 
proto tcp
auth-user-pass (...)


resolv-retry infinite 
redirect-gateway def1
persist-key
persist-tun
nobind
cipher AES-256-CBC
auth SHA256
ping 15
ping-exit 90
ping-timer-rem
script-security 2
remote-cert-tls server
route-delay 5                                                                                                                              
verb 4                                                                                                                                     
comp-lzo                                                                                                                                   
up /etc/openvpn/update-resolv-conf                                                                                                         
down /etc/openvpn/update-resolv-conf                                                                                                       
                                                                                                                                           
ca ca.crt                                                                                                                                  
                                                                                                                                           
cert client.crt                                                                                                                            
                                                                                                                                           
key client.key

Da steht nichts von IPv6 drin, soweit ich das erkennen kann. Die Datei vom Laptop ist identisch. Die zweite Zeile (remote 1-at.cg-dialup.net 443) "zeigt " jetzt auf Österreich und siehe da - es läuft. tausche ich at gegen z.B. de oder ch oder fi dann habe ich wieder diese ROUTE6-Zeilen in der syslog. Das lässt mich vermuten, dass der Fehler doch auf Seite des VPN-Providers liegt...

Und hier noch die update-resolv.conf, die bei up und down aufgerufen wird. Daraus werde ich nicht sehr schlau:

Code: Alles auswählen

# 
# Example envs set from openvpn:
#
#     foreign_option_1='dhcp-option DNS 193.43.27.132'
#     foreign_option_2='dhcp-option DNS 193.43.27.133'
#     foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
#

[ -x /sbin/resolvconf ] || exit 0
[ "$script_type" ] || exit 0
[ "$dev" ] || exit 0

split_into_parts()
{
        part1="$1"
        part2="$2"
        part3="$3"
}

case "$script_type" in
  up)
        NMSRVRS=""
        SRCHS=""
        for optionvarname in ${!foreign_option_*} ; do
                option="${!optionvarname}"
                echo "$option"
                split_into_parts $option
                if [ "$part1" = "dhcp-option" ] ; then
                        if [ "$part2" = "DNS" ] ; then
                                NMSRVRS="${NMSRVRS:+$NMSRVRS }$part3"
                        elif [ "$part2" = "DOMAIN" ] ; then
                                SRCHS="${SRCHS:+$SRCHS }$part3"
                        fi
                fi
        done
        R=""
        [ "$SRCHS" ] && R="search $SRCHS
"
        for NS in $NMSRVRS ; do
                R="${R}nameserver $NS
"
        done
        echo -n "$R" | /sbin/resolvconf -a "${dev}.openvpn"
        ;;
  down)
        /sbin/resolvconf -d "${dev}.openvpn"
        ;;
esac

[am2]

Ok, gelöst. CyberGhost hat vor einiger Zeit die Konfig-Datei verändert, u.a. gab's ein Protokollwechsel von tcp nach udp. Gut, dass mich niemand informiert hat und noch besser, dass der Support nicht darauf gekommen ist. Schließlich zahle ich etwas Geld dafür, dass es läuft. Na gut... Beide Rechner liefen noch mit der alten Konfig und der Server in Österreich kam noch damit klar. Nun ist die neue Konfig da und es gibt keine Probleme mehr.

[wanne]

Dann war die Fehlermeldung von OpenVPN ja mal wieder beeindruckend gut verständlich...
Genau aus dem Grund hasse ich das Ding.

[am2]

Tja. Ich war auch auf IPv6 fixiert. Die Konfig-Datei war eher ein Zufallsfund bzw.meine Hartnäckigkeit in diesem Fall. Aber solche "verständlichen" Meldungen kommen in der IT doch öfter vor

[chrssss]

Hallo,

ich erhalte die gleiche Fehlermeldung in Raspbian. Wie konnte das gelöst werden? Ich komme gar nicht weiter. Danke