Opened 4 years ago
Last modified 4 years ago
#1403 new Bug / Defect
retry logic is strange on hand-window fails
Reported by: | Gert Döring | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | release 2.6 |
Component: | Generic / unclassified | Version: | OpenVPN git master branch (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | plaisthos, Antonio Quartulli |
Description
Building a test rig for FP auth, I played with intentionally-failing client certs, and found that our understanding of --connect-retry-max 1
is... interesting.
$ ../bin/openvpn.master --client ... --connect-retry 1 --connect-retry-max 1 --hand-window 10 ... 2021-04-28 11:04:08 OpenVPN 2.6_git [git:vw1master/7064ccb9fd3578c0+] amd64-unknown-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Mar 23 2021 2021-04-28 11:04:08 library versions: OpenSSL 1.1.1h-freebsd 22 Sep 2020, LZO 2.10 2021-04-28 11:04:08 TCP/UDP: Preserving recently used remote address: [AF_INET6]2001:608:0:814::f000:11:51200 2021-04-28 11:04:08 Socket Buffers: R=[42080->42080] S=[9216->9216] 2021-04-28 11:04:08 UDP link local: (not bound) 2021-04-28 11:04:08 UDP link remote: [AF_INET6]2001:608:0:814::f000:11:51200 2021-04-28 11:04:08 TLS: Initial packet from [AF_INET6]2001:608:0:814::f000:11:51200, sid=c4256588 7d0c0b97 2021-04-28 11:04:08 VERIFY KU OK 2021-04-28 11:04:08 Validating certificate extended key usage 2021-04-28 11:04:08 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-04-28 11:04:08 VERIFY EKU OK 2021-04-28 11:04:08 VERIFY OK: depth=0, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net 2021-04-28 11:04:18 TLS Error: TLS key negotiation failed to occur within 10 seconds (check your network connectivity) 2021-04-28 11:04:18 TLS Error: TLS handshake failed 2021-04-28 11:04:18 SIGUSR1[soft,tls-error] received, process restarting 2021-04-28 11:04:18 Restart pause, 1 second(s) 2021-04-28 11:04:19 TCP/UDP: Preserving recently used remote address: [AF_INET]194.97.140.11:51200 2021-04-28 11:04:19 Socket Buffers: R=[42080->42080] S=[9216->9216] 2021-04-28 11:04:19 UDP link local: (not bound) 2021-04-28 11:04:19 UDP link remote: [AF_INET]194.97.140.11:51200 2021-04-28 11:04:19 TLS: Initial packet from [AF_INET]194.97.140.11:51200, sid=1402ed84 5446de2a 2021-04-28 11:04:19 VERIFY KU OK 2021-04-28 11:04:19 Validating certificate extended key usage 2021-04-28 11:04:19 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-04-28 11:04:19 VERIFY EKU OK 2021-04-28 11:04:19 VERIFY OK: depth=0, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net 2021-04-28 11:04:29 TLS Error: TLS key negotiation failed to occur within 10 seconds (check your network connectivity) 2021-04-28 11:04:29 TLS Error: TLS handshake failed 2021-04-28 11:04:29 SIGUSR1[soft,tls-error] received, process restarting 2021-04-28 11:04:29 Restart pause, 1 second(s) 2021-04-28 11:04:30 All connections have been connect-retry-max (1) times unsuccessful, exiting 2021-04-28 11:04:30 Exiting due to fatal error
so it actually tries twice, and then declares "all my (1) tries have failed"...
It does correctly count these on other connect fails...
This happens for 2.4 and master, so I assume it is a very long-standing bug.
Note: See
TracTickets for help on using
tickets.
Ah. This is related to the way we loop about dual-stack hosts.
If I force the client to use "only IPv4" or "only IPv6", it will try only once.
Still looking silly... but possibly the SRV patch will "fix" this as it rewrites these parts anyway.