Ergebnis 1 bis 7 von 7

Thema: AUTH: Received control message: AUTH_FAILED nach Reconnect

  1. #1
    IPPF Fünfhunderter Avatar von DoctorUltra
    Registriert seit
    04.08.2005
    Beiträge
    554

    AUTH: Received control message: AUTH_FAILED nach Reconnect

    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
    Code:
    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
    Code:
    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, emailAddress=secure@privateinternetaccess.com
    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, emailAddress=secure@privateinternetaccess.com
    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, emailAddress=secure@privateinternetaccess.com
    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, emailAddress=secure@privateinternetaccess.com
    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
    Router: Fritz 7050, 7141, 7390
    FW der Box: 14.04.33
    Internetzugang: T-DSL mit Congster Flat
    VOIP: GMX Flat, Sipgate, Telefonip, Internetcalls, Voipdiscount, LowrateVOIP, Poivy, VOIPStunt, Sparvoip, VOIP Discount, JustVoip

    Betriebssystem: Vista Ultimate
    Sonstiges: Telefon-Sparbuch LCR Updater, Pseudo Image, SSH



  2. #2
    IPPF-Einsteiger
    Registriert seit
    28.01.2008
    Beiträge
    25
    Mit in die config nehmen :

    float

  3. #3
    IPPF Fünfhunderter Avatar von DoctorUltra
    Registriert seit
    04.08.2005
    Beiträge
    554
    funktioniert leider nicht
    Router: Fritz 7050, 7141, 7390
    FW der Box: 14.04.33
    Internetzugang: T-DSL mit Congster Flat
    VOIP: GMX Flat, Sipgate, Telefonip, Internetcalls, Voipdiscount, LowrateVOIP, Poivy, VOIPStunt, Sparvoip, VOIP Discount, JustVoip

    Betriebssystem: Vista Ultimate
    Sonstiges: Telefon-Sparbuch LCR Updater, Pseudo Image, SSH



  4. #4
    IPPF-Einsteiger
    Registriert seit
    28.01.2008
    Beiträge
    25
    ok
    dann hätte ich noch

    auth-nocache

    anzubieten
    ansonsten im moment keine Ahnung

  5. #5
    IPPF Fünfhunderter Avatar von DoctorUltra
    Registriert seit
    04.08.2005
    Beiträge
    554
    geht auch nicht?
    Router: Fritz 7050, 7141, 7390
    FW der Box: 14.04.33
    Internetzugang: T-DSL mit Congster Flat
    VOIP: GMX Flat, Sipgate, Telefonip, Internetcalls, Voipdiscount, LowrateVOIP, Poivy, VOIPStunt, Sparvoip, VOIP Discount, JustVoip

    Betriebssystem: Vista Ultimate
    Sonstiges: Telefon-Sparbuch LCR Updater, Pseudo Image, SSH



  6. #6
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.939
    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/openvp...gesInOpenvpn23 - 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.

  7. #7
    IPPF Fünfhunderter Avatar von DoctorUltra
    Registriert seit
    04.08.2005
    Beiträge
    554
    Das auth-retry war es danke
    Router: Fritz 7050, 7141, 7390
    FW der Box: 14.04.33
    Internetzugang: T-DSL mit Congster Flat
    VOIP: GMX Flat, Sipgate, Telefonip, Internetcalls, Voipdiscount, LowrateVOIP, Poivy, VOIPStunt, Sparvoip, VOIP Discount, JustVoip

    Betriebssystem: Vista Ultimate
    Sonstiges: Telefon-Sparbuch LCR Updater, Pseudo Image, SSH



Ähnliche Themen

  1. Correct auth, but based on stale nonce received from ...
    Von Taaz im Forum Asterisk Allgemein
    Antworten: 2
    Letzter Beitrag: 05.01.2015, 21:26
  2. Rufe auf bestimmtes Telefon erst nach Auth verbinden
    Von klassenblatt im Forum Asterisk Allgemein
    Antworten: 1
    Letzter Beitrag: 09.08.2012, 10:13
  3. Zeitsync nach reconnect?
    Von cwarlich im Forum Freetz
    Antworten: 1
    Letzter Beitrag: 22.02.2012, 11:25
  4. Syslog nach DSL-Reconnect
    Von Sysop99 im Forum Freetz
    Antworten: 1
    Letzter Beitrag: 29.10.2007, 20:33
  5. Message Waiting Indication (MWI): von welchem Provider kommt die Message ?
    Von McMephistoXXL im Forum FRITZ!Box Fon: Telefonie
    Antworten: 3
    Letzter Beitrag: 22.05.2006, 10:30

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •