OPENVPN kein reconnect after reboot

Karsten

Moin,
ich habe eine netgate 3100 mit der aktuellen Firmware 22.01. Diese soll sich mit einer Sophos verbinden per OPENVPN verbinden. Das funktioniert auch alles tadellos.
Allerdings nach dem reboot gibt es einen TLS-Handshake Error. Sobald ich das Kennwort bei den "User Authentication Settings" wieder eintrage, wird die Verbindung wieder aufgebaut.
Ich habe bereits eine neue Verbindung auf beiden Seiten konfiguriert. Der Fehler tritt immer wieder nach dem reboot auf.

Apr 14 10:03:31 openvpn 47783 UDPv4 link local: (not bound)
Apr 14 10:03:31 openvpn 47783 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:8443
Apr 14 10:03:31 openvpn 47783 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 14 10:03:21 openvpn 47783 SIGUSR1[soft,tls-error] received, process restarting
Apr 14 10:03:21 openvpn 47783 TLS Error: TLS handshake failed
Apr 14 10:03:21 openvpn 47783 TLS Error: TLS object -> incoming plaintext read error
Apr 14 10:03:21 openvpn 47783 TLS_ERROR: BIO read tls_read_plaintext error
Apr 14 10:03:21 openvpn 47783 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

VG
Karsten

micneu

@karsten bitte mal einen grafischen netzwerkplan. so können wir nur raten wie du ins internet kommst (hast du dsl, glas oder kabel) bitte so viel informationen wie möglich.
hier nochmal die fragen:

bitte einen grafischen netzerkplan
in diesem bitte genau angeben wie du ins internet kommst
ist das WAN direkt an der sense?

ich hatte damals mal probleme als eine fritzbox die einwahl gemacht hatte (besonders mit ipsec)

Karsten

Moin,
die Sense hängt in einem Testnetz hinter einer Lancom 1781, die wiederum am Glasfaser hängt, im Internet. Die Firewall auf der Lancom ist für die Sense auf "Durchzug" geschaltet (any - any). Bislang hat das bei allen anderen Testaufbauten mit den gleichen Geräten auch immer tadellos funktioniert.

Aber manchmal hilft auch ein wenig Geduld. Als ich heute nach Ostern wieder ins Büro kam, hatte sich die Sense auch wieder von selbst verbunden :-)

viragomann

@karsten
Hallo,

der Fehler kann grundsätzlich ganz unterschiedlichen Ursachen haben.

Wenn die Verbindung aber mal funktioniert, mal nicht, solltest du die Uhren der beiden Systeme vergleichen. Natürlich in letzterem Fall. Eventuell läuft da eine daneben und synchronisiert sich dann wieder.

Karsten

Moin,
das Problem besteht weiterhin. Jetzt auch bei anderen netgate Routern, mit ähnlicher Konfiguration. Sobald ich in den "User Authentication Settings" das Kennwort erneut eintrage, verbindet sich der Router wieder per VPN. Aber nach jeder Zwangstrennung in der Nacht oder auch nach manueller Trennung der VPN-Verbindung, hängt der Verbindungsaufbau..

Kann es sein, dass mit der aktuellen Build das Kennwort nicht mehr gespeichert wird?

VG
Karsten

micneu

@karsten

warum musst du benutzername/passwort für eine openvpn verbindung angeben?
bitte mal einen grafischen netzwerkplan
ist das ein s2s oder rw openvpn?
hört sich für mich so an als wenn du dich mit einem rw openvpn mit der sense verbindest?
wer ist server und wer client?

Karsten

@micneu

Die netGate verbindet sich per SSL VPN als Site2Site mit der Sophos

micneu

@karsten du brauchst für ein s2s benutzername und passwort, das kenne ich mit psk oder zertifikate?

Karsten

@micneu Na klar. Bei der OpenVPN Client Einrichtung müssen Benutzername und Kennwort eingetragen werden.

viragomann

@karsten
Vielleicht könnte ein größerer Log-Ausschnitt einen Aufschluss auf die mögliche Ursache geben.
Auch das System-Log ab Internet-Trennung wäre interessant.

Wie sieht der Uhrenvergleich aus?

Welche Versionen sind das?

Karsten

@viragomannMoin,
Die Uhrzeit geht richtig. Hier ist das Log:

Jun 8 09:42:25 openvpn 4744 MANAGEMENT: Client disconnected
Jun 8 09:42:25 openvpn 4744 MANAGEMENT: CMD 'state 1'
Jun 8 09:42:25 openvpn 4744 MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Jun 8 09:42:24 openvpn 4744 Restart pause, 10 second(s)
Jun 8 09:42:24 openvpn 4744 SIGUSR1[soft,tls-error] received, process restarting
Jun 8 09:42:24 openvpn 4744 TCP/UDP: Closing socket
Jun 8 09:42:24 openvpn 4744 TLS Error: TLS handshake failed
Jun 8 09:42:24 openvpn 4744 TLS Error: TLS object -> incoming plaintext read error
Jun 8 09:42:24 openvpn 4744 TLS_ERROR: BIO read tls_read_plaintext error
Jun 8 09:42:24 openvpn 4744 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Jun 8 09:42:24 openvpn 4744 VERIFY EKU ERROR
Jun 8 09:42:24 openvpn 4744 Certificate does not have extended key usage extension
Jun 8 09:42:24 openvpn 4744 VERIFY KU OK
Jun 8 09:42:24 openvpn 4744 VERIFY OK: depth=1, C=de, L=Hamburg, O=xxx
Jun 8 09:42:24 openvpn 4744 VERIFY WARNING: depth=1, unable to get certificate CRL: C=de, L=Hamburg, xxx
Jun 8 09:42:24 openvpn 4744 VERIFY WARNING: depth=0, unable to get certificate CRL: C=de, L=Hamburg, xxx

pid=3 DATA len=884

Jun 8 09:42:24 openvpn 4744 UDPv4 WRITE [22] to [AF_INET]xxx:8443: P_ACK_V1 kid=0 [ 2 ]

pid=2 DATA len=1174

Jun 8 09:42:24 openvpn 4744 UDPv4 WRITE [22] to [AF_INET]xxx:8443: P_ACK_V1 kid=0 [ 1 ]
Jun 8 09:42:24 openvpn 4744 UDPv4 READ [1200] from [AF_INET]xxx:8443: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=1174

pid=1 DATA len=277

Jun 8 09:42:24 openvpn 4744 UDPv4 WRITE [22] to [AF_INET]xxx:8443: P_ACK_V1 kid=0 [ 0 ]
Jun 8 09:42:24 openvpn 4744 TLS: Initial packet from [AF_INET]xxx:8443, sid=2aa28350 7c17c08c
Jun 8 09:42:24 openvpn 4744 UDPv4 READ [26] from [AF_INET]xxx:8443: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0

pid=0 DATA len=0

Jun 8 09:42:24 openvpn 4744 UDPv4 link remote: [AF_INET]xxx:8443
Jun 8 09:42:24 openvpn 4744 UDPv4 link local (bound): [AF_INET]xxx:0
Jun 8 09:42:24 openvpn 4744 Socket Buffers: R=[42080->42080] S=[57344->57344]
Jun 8 09:42:24 openvpn 4744 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx:8443
Jun 8 09:42:24 openvpn 4744 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Jun 8 09:42:24 openvpn 4744 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Jun 8 09:42:24 openvpn 4744 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Jun 8 09:42:24 openvpn 4744 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Jun 8 09:42:24 openvpn 4744 LZO compression initializing
Jun 8 09:42:24 openvpn 4744 Re-using SSL/TLS context
Jun 8 09:42:24 openvpn 4744 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 8 09:42:16 openvpn 4744 MANAGEMENT: Client disconnected
Jun 8 09:42:16 openvpn 4744 MANAGEMENT: CMD 'state 1'
Jun 8 09:42:16 openvpn 4744 MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock

Ich könnte mir vorstellen, das es hiemit zu tun hat:
"Certificate does not have extended key usage extension"

Karsten

@karsten ich denke, ich habe was gefunden:

https://redmine.pfsense.org/issues/13056

Nachdem ich den Patch eingespielt habe, konnte ich den Haken wieder rausnehmen:

viragomann

@karsten

ich denke, ich habe was gefunden:

https://redmine.pfsense.org/issues/13056

Nachdem ich den Patch eingespielt habe, konnte ich den Haken wieder rausnehmen:

Aber das ist nun neu. Die Zeilen

Jun 8 09:42:24 openvpn 4744 VERIFY EKU ERROR
Jun 8 09:42:24 openvpn 4744 Certificate does not have extended key usage extension

hat dein erstes Log nicht gezeigt.

Sollte damit funktionieren. Nach meiner Info müssen beide Patches eingespielt werden. Hier schon mal erwähnt:
https://forum.netgate.com/topic/172313/openvpn-endian-site-to-site-tls-error-reconnecting/2

Karsten

@viragomann Ich habe das LOG-Level hochgedreht. Da kam dann auch die neue Meldung zum Vorschein :-)

Vielen Dank für Deine Hilfe, jetzt läuft es wieder.
Karsten

viragomann

@karsten said in OPENVPN kein reconnect after reboot:

Ich habe das LOG-Level hochgedreht. Da kam dann auch die neue Meldung zum Vorschein :-)

Ahh, alles klar.