Transmission not starting. Inactivity Timeout.

[Sal-Tepedino]

This is the configuration I've been using for quite some time now, and it's been working fine (usually), however recently, the container keeps restarting after a timeout from OpenVPN, and the container never starts Transmission. I'm not sure if this is an issue with the container or SlickVPN. I've tried several different versions, including the main branch, dev, 3.7.1. None of them work, though 3.7.1 doesn't exit, it just loops. I've tried several different locations, and though some of them don't work for cert or DNS reasons, Charlotte at least does. I pasted it's log below. I had this same issue with a few other locations as well, so it's not limited to this one.
I've searched through the issues and discussions, but can't find anything that fits my issue, and I've tried tweaking several parts of the config to try to get it to be happy, but it just doesn't want to work.
I'm more inclined to think it might be an issue with the VPN, or at least the config for the VPN, rather than the container itself, but the logs don't give me much to go on. Setting debug mode gives me the commands run, but not what's causing the timeout.
I've even tried 'custom' with ovpn files directly from SlickVPN.

Any suggestions on how to track down this issue?

I've downloaded every current US config from SlickVPN (https://www.slickvpn.com/locations/) and had a one-liner going through each config in order to try them all. None of them worked. Some failed with OpenSSL errors (CA signature digest algorithm too weak), which are obviously not container issues, but several of them failed with the timeout issue below.

Edit: I changed the version to 3.7.1 and let my random config script run and it's working now. Guess it's a combination of the newer version's OpenSSL not liking SlickVPN and perhaps some of the sites being down? Still would like to track down what's stopping the newer version from working.

Edit 2: At this point, I'm thinking it's an OpenSSL digest algorithm problem, and that the new version doesn't support the algorithms that my VPN does. So the question, I think, has become is: How do I adjust the algorithms allowed within the container?

Starting container with revision: b33d0fe
Creating TUN device /dev/net/tun
Using OpenVPN provider: SLICKVPN
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for SLICKVPN. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.nWwgDbXmWm
Extracting configs to /tmp/tmp.gAQVEvMXn8
Found configs for SLICKVPN in /tmp/tmp.gAQVEvMXn8/vpn-configs-contrib-main/openvpn/slickvpn, will replace current content in /etc/openvpn/slickvpn
Cleanup: deleting /tmp/tmp.nWwgDbXmWm and /tmp/tmp.gAQVEvMXn8
4 servers found in OPENVPN_CONFIG, United-States-Charlotte chosen randomly
Starting OpenVPN using config United-States-Charlotte.ovpn
Modifying /etc/openvpn/slickvpn/United-States-Charlotte.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Modification: Updating status for config failure detection
Setting OpenVPN credentials...
adding route to local network 10.1.1.0/24 via 172.18.0.1 dev eth0
2022-11-19 00:55:26 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2022-11-19 00:55:26 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
2022-11-19 00:55:26 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2022-11-19 00:55:26 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2022-11-19 00:55:26 TCP/UDP: Preserving recently used remote address: [AF_INET]155.254.29.103:443
2022-11-19 00:55:26 Socket Buffers: R=[212992->212992] S=[212992->212992]
2022-11-19 00:55:26 UDP link local: (not bound)
2022-11-19 00:55:26 UDP link remote: [AF_INET]155.254.29.103:443
2022-11-19 00:56:26 [UNDEF] Inactivity timeout (--ping-exit), exiting
2022-11-19 00:56:26 SIGTERM[soft,ping-exit] received, process exiting

[brotherduck]

Some providers seem to be broken with latest version, in my case (Ghostpath) I've temporarily fixed this by adding "OPENVPN_OPTS=--tls-cipher DEFAULT:@SECLEVEL=0" to my run command.

[Sal-Tepedino]

This fixed it. Figured it was a 'problem' caused by the update to the container being too secure with the ciphers involved. I put this into my docker-compose setup and it worked the first shot.

Thanks!