Anybody else suddenly started having IPvanish issues? Log shows no auth probs, but container is timing out with no connection.

[kosmonot]

Been using this for years on with no issues, but suddenly it's not working. Username/pw still valid to log on to their website. I tried multiple servers worldwide. No auth error message, but container launches suspiciously fast from stack update.

Docker was just updated yesterday, so there's that. Similar PIA config still working fine.

Portainer stack:

services:
    transmission-openvpn:
        cap_add:
            - NET_ADMIN
        dns:
            - 1.1.1.1
            - 9.9.9.9
        volumes:
            - /home/username/media/trans/data:/data
            - /home/username/media/trans/config:/config
            - /home/username/ipvanish/configs:/etc/openvpn/custom
            - /home/username/media/trans/data/watch:/watch
            - /home/username/media/trans/data/completed:/completed
            - /home/username/media/trans/data/incomplete:/incomplete
        environment:
            - OPENVPN_PROVIDER=CUSTOM
            - OPENVPN_CONFIG=ipvanish-US-Ashburn-iad-a69
            - OPENVPN_USERNAME=XXXXX
            - OPENVPN_PASSWORD=XXXXX
            - LOCAL_NETWORK=192.168.0.0/16
            - TRANSMISSION_RPC_USERNAME=XXXXX
            - TRANSMISSION_RPC_PASSWORD=XXXXX
            - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
            - GLOBAL_APPLY_PERMISSIONS=false
        logging:
            driver: json-file
            options:
                max-size: 10m
        ports:
            - '9099:9091'
        image: haugene/transmission-openvpn:latest

Logfile:

Starting container with revision: 07f5a2b9aea5028c9bb75438c1552708e91dde71
TRANSMISSION_HOME is currently set to: /config/transmission-home
Creating TUN device /dev/net/tun
Using OpenVPN provider: CUSTOM
Running with VPN_CONFIG_SOURCE auto
CUSTOM provider specified but not using default.ovpn, will try to find a valid config mounted to /etc/openvpn/custom
Starting OpenVPN using config ipvanish-US-Ashburn-iad-a69.ovpn
Modifying /etc/openvpn/custom/ipvanish-US-Ashburn-iad-a69.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 192.168.0.0/16 via 172.31.0.1 dev eth0
2024-02-07 18:48:43 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-02-07 18:48:43 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.
2024-02-07 18:48:43 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
2024-02-07 18:48:43 OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 29 2023
2024-02-07 18:48:43 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2024-02-07 18:48:43 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-02-07 18:48:43 TCP/UDP: Preserving recently used remote address: [AF_INET]216.151.191.163:443
2024-02-07 18:48:43 Socket Buffers: R=[212992->212992] S=[212992->212992]
2024-02-07 18:48:43 UDP link local: (not bound)
2024-02-07 18:48:43 UDP link remote: [AF_INET]216.151.191.163:443
2024-02-07 18:49:43 [UNDEF] Inactivity timeout (--ping-exit), exiting
2024-02-07 18:49:43 SIGTERM[soft,ping-exit] received, process exiting

[edgd1er]

PIA is well know for its outdated cipher, options and set up.

2024-02-07 18:48:43 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.
2024-02-07 18:48:43 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6

The problem here seems to be ping-exit. here is the doc that explains that option: https://haugene.github.io/docker-transmission-openvpn/faq/#set_the_ping-exit_option_for_openvpn_and_restart-flag_in_docker

[kosmonot]

This is IPVanish, but I know what you mean about those deprecated cipher warnings in the logs. PIA has a similar one for me
DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-128-cbc' to --data-ciphers or change --cipher 'aes-128-cbc' to --data-ciphers-fallback 'aes-128-cbc' to silence this warning. and still authenticates and connects properly. The ping-exit doesn't seem to be the problem here--it's just a response to the connect failure, yes?

[edgd1er]

my understanding is that ping setting is not properly set, hence jsut after auth, openvpn sends a sigtem to the container. You should force a decent value like suggested in the doc.

[kosmonot]

The log is not properly timestamping--the ping exit actually happens ~60 seconds after 18:48:43 UDP link remote: [AF_INET]216.151.191.163:443

[kosmonot]

Oops, I must have cut and paste and got the the wrong timestamp copy pasting the log somehow--my sincere apologies. Here's a proper one:

2024-02-07 22:05:00 UDP link remote: [AF_INET]216.151.191.157:443
2024-02-07 22:06:01 [UNDEF] Inactivity timeout (--ping-exit), exiting
2024-02-07 22:06:01 SIGTERM[soft,ping-exit] received, process exiting

[edgd1er]

seems similar to #1545

[kosmonot]

It started connecting again but I had to comment out my custom DNS config and use their servers to get it to work. It's also requiring frequent container restarts. Looks like I will not be renewing contract next month.