use setup_tun callback to defer printing connection status AND backgrounding until tun_is_up
This will make scripted use of OpenConnect a lot less sensitive to timing of the tunnel
coming up, if a script is trying to use the tunnel as soon as the main process exits.
(See https://gitlab.com/openconnect/openconnect/-/issues/117 for examples.)
Here's a log of OpenConnect connecting to a GlobalProtect server where ESP
fails to start succesfully due to a firewall blocking UDP. With this
change, it doesn't print the connection status or go to background until after the
attempt to connect ESP has failed, and the tunnel has been started.
$ echo PASSWORD | sudo ./openconnect -u USERNAME vpn.company.com/gateway --prot=gp --passwd-on-stdin -b \ -s echo +++ vpnc-script called with reason $reason
POST https://vpn.company.com/ssl-vpn/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to 1.2.3.4:443
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
Enter login credentials
POST https://vpn.company.com/ssl-vpn/login.esp
POST https://vpn.company.com/ssl-vpn/getconfig.esp
Session will expire after 1440 minutes.
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
No MTU received. Calculated 1214 for ESP tunnel
POST https://vpn.company.com/ssl-vpn/hipreportcheck.esp
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Failed to connect ESP tunnel; using HTTPS instead.
Connected as 10.0.1.2, using SSL, with ESP unsuccessful
Continuing in background; pid 1234
+++ vpnc-script called with reason pre-init
+++ vpnc-script called with reason connect
$
Here's an example of attempted DTLS connecting on an AnyConnect VPN, where DTLS
never succeeds. This right away gives us some good feedback that we could probably
reduce the duration of the loop:
Connected to 1.2.3.4:443
SSL negotiation with vpn.company.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(ECDHE-RSA-SECP384R1)-(AES-256-GCM)
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
DTLS handshake failed: Resource temporarily unavailable, try again.
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Connected as 10.0.1.2, using SSL, with DTLS in progress
Signed-off-by: Daniel Lenski <email address hidden>
There's no clear rationale for using with Pulse/oNCP ESP setup (yet):
- We don't do any MTU detection
- Unlike GPST, we can start sending and receiving packets via the TLS tunnel
immediately, while attempting to connect ESP as well.
Signed-off-by: Daniel Lenski <email address hidden>
- If delay_tunnel_reason is set, mainloop will defer tunnel device creation for one more iteration.
- If delay_close is set, mainloop will continue to iterate even if cancel_cmd or pause_cmd is set.
- If delay_close==1, we don't set did_work; if >=1 we do.
- This allows a protocol to set delay_close=2 for the case where its
mainloop needs an immediate callback to send a termination request, and
delay_close=1 for the case where a protocol needs to wait for a
termination acknowledgment.
openconnect_mainloop() decrements delay_close, and set delay_tunnel_reason to NULL, on each
iteration. A protocol mainloop must thus affirmatively extend a delay in order for it to
continue.
Signed-off-by: Daniel Lenski <email address hidden>
