AUTH: Received control message: AUTH_FAILED nach Reconnect

[DoctorUltra]

Hallo habt Ihr eine Idee dazu.

Dieser Fehler passiert nur nach der nächtlichen Zwangstrennung?
Wenn ich einen Restart des Service mache läuft wieder alles bis zur nächsten Zwangstrennung?

Config

client
dev tun 
proto udp
#remote nl.privateinternetaccess.com 1194
#remote nl.privateinternetaccess.com 9201
remote sweden.privateinternetaccess.com 1194
#remote sweden.privateinternetaccess.com 1198
resolv-retry infinite
nobind
persist-key
#persist-tun
tls-client
remote-cert-tls server
auth-user-pass /etc/openvpn/passfile
comp-lzo
verb 3
#verb 9
log /tmp/debug_openvpn.out
reneg-sec 0
crl-verify /etc/openvpn/crl.pem
#crl-verify /etc/openvpn/crl.rsa.2048.pem
ca /etc/openvpn/ca.crt
#ca /etc/openvpn/ca.rsa.2048.crt
#disable-occ
#script-security 2
#up /etc/openvpn/addroute.sh

Log

Sat Apr  8 12:55:32 2017 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Sat Apr  8 12:55:32 2017 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.08
Sat Apr  8 12:55:32 2017 WARNING: file '/etc/openvpn/passfile' is group or others accessible
Sat Apr  8 12:55:32 2017 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sat Apr  8 12:55:32 2017 RESOLVE: Cannot resolve host address: sweden.privateinternetaccess.com: Temporary failure in name resolution
Sat Apr  8 12:55:32 2017 RESOLVE: Cannot resolve host address: sweden.privateinternetaccess.com: Temporary failure in name resolution
Sat Apr  8 12:55:37 2017 UDPv4 link local (bound): [undef]
Sat Apr  8 12:55:37 2017 UDPv4 link remote: [AF_INET]5.153.233.34:1194
Sat Apr  8 12:55:37 2017 TLS: Initial packet from [AF_INET]5.153.233.34:1194, sid=aa375c04 03c75688
Sat Apr  8 12:55:37 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Apr  8 12:55:37 2017 CRL CHECK OK: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sat Apr  8 12:55:37 2017 VERIFY OK: depth=1, C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sat Apr  8 12:55:37 2017 Validating certificate key usage
Sat Apr  8 12:55:37 2017 ++ Certificate has key usage  00a0, expects 00a0
Sat Apr  8 12:55:37 2017 VERIFY KU OK
Sat Apr  8 12:55:37 2017 Validating certificate extended key usage
Sat Apr  8 12:55:37 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr  8 12:55:37 2017 VERIFY EKU OK
Sat Apr  8 12:55:37 2017 CRL CHECK OK: C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=099d8640923d949ef9448bc9aa948bd2, name=099d8640923d949ef9448bc9aa948bd2
Sat Apr  8 12:55:37 2017 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=099d8640923d949ef9448bc9aa948bd2, name=099d8640923d949ef9448bc9aa948bd2
Sat Apr  8 12:55:38 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Apr  8 12:55:38 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Apr  8 12:55:38 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Apr  8 12:55:38 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Apr  8 12:55:38 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Apr  8 12:55:38 2017 [099d8640923d949ef9448bc9aa948bd2] Peer Connection Initiated with [AF_INET]5.153.233.34:1194
Sat Apr  8 12:55:40 2017 SENT CONTROL [099d8640923d949ef9448bc9aa948bd2]: 'PUSH_REQUEST' (status=1)
Sat Apr  8 12:55:40 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.42.10.1,topology net30,ifconfig 10.42.10.6 10.42.10.5,auth-token Ir9qCT5z27sMtfWvLDMVeWmn13yWQlT4j0oZP+n/WJA='
Sat Apr  8 12:55:40 2017 OPTIONS IMPORT: timers and/or timeouts modified
Sat Apr  8 12:55:40 2017 OPTIONS IMPORT: LZO parms modified
Sat Apr  8 12:55:40 2017 OPTIONS IMPORT: --ifconfig/up options modified
Sat Apr  8 12:55:40 2017 OPTIONS IMPORT: route options modified
Sat Apr  8 12:55:40 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Apr  8 12:55:40 2017 ROUTE_GATEWAY 192.168.10.1/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:02:e6:33
Sat Apr  8 12:55:40 2017 TUN/TAP device tun0 opened
Sat Apr  8 12:55:40 2017 TUN/TAP TX queue length set to 100
Sat Apr  8 12:55:40 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Apr  8 12:55:40 2017 /sbin/ip link set dev tun0 up mtu 1500
Sat Apr  8 12:55:40 2017 /sbin/ip addr add dev tun0 local 10.42.10.6 peer 10.42.10.5
Sat Apr  8 12:55:40 2017 /sbin/ip route add 5.153.233.34/32 via 192.168.10.1
Sat Apr  8 12:55:40 2017 /sbin/ip route add 0.0.0.0/1 via 10.42.10.5
Sat Apr  8 12:55:40 2017 /sbin/ip route add 128.0.0.0/1 via 10.42.10.5
Sat Apr  8 12:55:40 2017 /sbin/ip route add 10.42.10.1/32 via 10.42.10.5
Sat Apr  8 12:55:40 2017 Initialization Sequence Completed
Sun Apr  9 06:00:06 2017 [099d8640923d949ef9448bc9aa948bd2] Inactivity timeout (--ping-restart), restarting
Sun Apr  9 06:00:06 2017 /sbin/ip route del 10.42.10.1/32
Sun Apr  9 06:00:06 2017 /sbin/ip route del 5.153.233.34/32
Sun Apr  9 06:00:06 2017 /sbin/ip route del 0.0.0.0/1
Sun Apr  9 06:00:06 2017 /sbin/ip route del 128.0.0.0/1
Sun Apr  9 06:00:06 2017 Closing TUN/TAP interface
Sun Apr  9 06:00:06 2017 /sbin/ip addr del dev tun0 local 10.42.10.6 peer 10.42.10.5
Sun Apr  9 06:00:06 2017 SIGUSR1[soft,ping-restart] received, process restarting
Sun Apr  9 06:00:06 2017 Restart pause, 2 second(s)
Sun Apr  9 06:00:08 2017 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Apr  9 06:00:08 2017 UDPv4 link local (bound): [undef]
Sun Apr  9 06:00:08 2017 UDPv4 link remote: [AF_INET]91.108.183.171:1194
Sun Apr  9 06:00:08 2017 TLS: Initial packet from [AF_INET]91.108.183.171:1194, sid=05b04165 4f876f7e
Sun Apr  9 06:00:08 2017 CRL CHECK OK: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sun Apr  9 06:00:08 2017 VERIFY OK: depth=1, C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sun Apr  9 06:00:08 2017 Validating certificate key usage
Sun Apr  9 06:00:08 2017 ++ Certificate has key usage  00a0, expects 00a0
Sun Apr  9 06:00:08 2017 VERIFY KU OK
Sun Apr  9 06:00:08 2017 Validating certificate extended key usage
Sun Apr  9 06:00:08 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Apr  9 06:00:08 2017 VERIFY EKU OK
Sun Apr  9 06:00:08 2017 CRL CHECK OK: C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=ff6b04366cb02a5d65bf3bb8d0bb8c77, name=ff6b04366cb02a5d65bf3bb8d0bb8c77
Sun Apr  9 06:00:08 2017 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=ff6b04366cb02a5d65bf3bb8d0bb8c77, name=ff6b04366cb02a5d65bf3bb8d0bb8c77
Sun Apr  9 06:00:08 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Apr  9 06:00:08 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Apr  9 06:00:08 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Apr  9 06:00:08 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Apr  9 06:00:08 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Apr  9 06:00:08 2017 [ff6b04366cb02a5d65bf3bb8d0bb8c77] Peer Connection Initiated with [AF_INET]91.108.183.171:1194
Sun Apr  9 06:00:10 2017 SENT CONTROL [ff6b04366cb02a5d65bf3bb8d0bb8c77]: 'PUSH_REQUEST' (status=1)
Sun Apr  9 06:00:10 2017 AUTH: Received control message: AUTH_FAILED
Sun Apr  9 06:00:10 2017 SIGTERM[soft,auth-failure] received, process exiting

Grüße

Dennis

 

[feedzapper]

Mit in die config nehmen :

float

 

[DoctorUltra]

funktioniert leider nicht :-(

 

[feedzapper]

ok
dann hätte ich noch

auth-nocache

anzubieten
ansonsten im moment keine Ahnung :-(

 

[DoctorUltra]

geht auch nicht?

 

[PeterPawn]

Hmm ... was ist das denn für eine FRITZ!Box, die mit einer ARM-basierten OpenVPN-Variante arbeitet? Bei den Modellen in der Signatur habe ich da so meine Probleme, die irgendwie in diesen Zusammenhang zu bringen. Es ist nicht doch zufällig ein RasPi und der Fragesteller hier im Forum "verrutscht"?

Ansonsten könnte man mal die Option "auth-retry" setzen ... wobei ich nicht weiß, wie sich "interact" und "nointeract" verhalten, wenn der "up"-Parameter (das steht für User/Password und hat nichts mit "up or down" zu tun) auf eine statische Datei verweist (da könnten ggf. die Rechte fehlen, wenn der Daemon welche abgegeben hat - kann ich hier in der Konfiguration aber nichts von erkennen). Ich wüßte gerade nicht, wo das näher beschrieben ist, also würde ich einen Test empfehlen ("Neu verbinden" bei der FRITZ!Box sollte dieselbe Situation heraufbeschwören wie eine Zwangstrennung) und dabei jeweils eine der beiden anderen möglichen Optionen verwenden ... nur der Standard "none" ist sicherlich eine eher schlechte Wahl (jedenfalls solange es nichts gibt, was die damit dann beendete OpenVPN-Instanz "von außen" neu startet).

Da es ja eine komplett neue Client-Instanz (wenn auch "soft") von OpenVPN ist (nach dem "ping-restart", was im Client-Mode standardmäßig auf 120 Sekunden steht), die hier (obendrein noch zu einer anderen IP-Adresse für den DNS-Namen und damit wohl auch zu einer anderen Server-Instanz) Kontakt aufnehmen will, kann es eigentlich nichts mit irgendwelchen zwischengespeicherten Daten zu tun haben ... entweder der Server kennt die Daten wirklich nicht oder der Client sendet Quatsch. Interessant wäre es halt, ob es wirklich nach jeder Zwangstrennung auftritt und welcher der Zugangsserver von PIA davon jeweils betroffen ist. Welchen Weg der Authentifizierung der Client wählt, sollte er bei einer höheren Stufe der Protokollierung zumindest einmal erwähnen.

Andererseits ist die hier verwendete Version von OpenVPN 2.3 auch schon so "angegraut" (die aktuelle wäre 2.3.14), daß es auch durchaus denkbar wäre, daß hier das einmal vom (ersten) Server übermittelte "auth-token" auch den "soft"-Restart überlebt und nun auch bei dem anderen Server fälschlicherweise(?) anstelle von Benutzer und Kennwort präsentiert wird. Vielleicht hilft ja ein Blick in die Changelogs von OpenVPN: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 - wobei das wohl auch nur bei der Suche nach der eigentlichen Ursache und weniger nach einer Lösung von Interesse sein dürfte. Obwohl man - gesetzt den Fall, es gab so ein inzwischen korrigiertes Problem - dann ja auch wüßte, auf welche Version man mind. aktualisieren müßte, damit der Client tatsächlich wieder den Benutzernamen und das Kennwort anstelle eines "auth-tokens" vom falschen Server verwendet.

- - - Aktualisiert - - -

BTW ... die Angabe von "tls-client" in Kombination mit "client" ist redundant - kein Beinbruch, aber in den meisten Fällen auch ein Zeichen dafür, daß sich da jemand eher an irgendwelchen "templates" orientiert hat und weniger selbst versuchte, die verwendeten Optionen zu verstehen (und dann ggf. zu hinterfragen).

- - - Aktualisiert - - -

Zweite Ergänzung ... der erwähnte "up"-Parameter ist der Dateinamen nach der Option "auth-user-pass", das wird oben vielleicht nicht deutlich genug.

 

[DoctorUltra]

Das auth-retry war es danke