Opened 3 years ago

Last modified 3 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.

Change History (1)

comment:1 Changed 3 years ago by Gert Döring

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.

Note: See TracTickets for help on using tickets.