haugene / vpn-configs-contrib

A collection of configs for various VPN providers
GNU General Public License v3.0
180 stars 744 forks source link

SlickVPNCore Not Connecting After Cert Update #99

Closed philbar closed 2 years ago

philbar commented 2 years ago

Is there a pinned issue for this?

Is there an existing or similar issue for this?

Is there any comment in the documentation for this?

Is this related to the container/transmission?

Are you using the latest release?

Have you tried using the dev branch latest?

Config used

{ "CapAdd" : [ "NET_ADMIN" ], "CapDrop" : [], "cmd" : "dumb-init /etc/openvpn/start.sh", "cpu_priority" : 50, "enable_publish_all_ports" : false, "enable_restart_policy" : false, "enabled" : true, "env_variables" : [ { "key" : "PATH", "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }, { "key" : "OPENVPN_USERNAME", "value" : "" }, { "key" : "OPENVPN_PASSWORD", "value" : "" }, { "key" : "OPENVPN_PROVIDER", "value" : "slickvpncore" }, { "key" : "GLOBAL_APPLY_PERMISSIONS", "value" : "true" }, { "key" : "TRANSMISSION_HOME", "value" : "/data/transmission-home" }, { "key" : "TRANSMISSION_RPC_PORT", "value" : "9091" }, { "key" : "TRANSMISSION_DOWNLOAD_DIR", "value" : "/data/completed" }, { "key" : "TRANSMISSION_INCOMPLETE_DIR", "value" : "/data/incomplete" }, { "key" : "TRANSMISSION_WATCH_DIR", "value" : "/data/watch" }, { "key" : "CREATE_TUN_DEVICE", "value" : "true" }, { "key" : "ENABLE_UFW", "value" : "false" }, { "key" : "UFW_ALLOW_GW_NET", "value" : "false" }, { "key" : "UFW_EXTRA_PORTS", "value" : "" }, { "key" : "UFW_DISABLE_IPTABLES_REJECT", "value" : "false" }, { "key" : "PUID", "value" : "" }, { "key" : "PGID", "value" : "" }, { "key" : "PEER_DNS", "value" : "true" }, { "key" : "PEER_DNS_PIN_ROUTES", "value" : "true" }, { "key" : "DROP_DEFAULT_ROUTE", "value" : "" }, { "key" : "WEBPROXY_ENABLED", "value" : "false" }, { "key" : "WEBPROXY_PORT", "value" : "8118" }, { "key" : "WEBPROXY_USERNAME", "value" : "" }, { "key" : "WEBPROXY_PASSWORD", "value" : "" }, { "key" : "LOG_TO_STDOUT", "value" : "false" }, { "key" : "HEALTH_CHECK_HOST", "value" : "google.com" }, { "key" : "SELFHEAL", "value" : "false" }, { "key" : "REVISION", "value" : "20877f1b168b6ff27fc58aeef40756572c562d47" }, { "key" : "OPENVPN_CONFIG", "value" : "Romania-Bucharest, Netherlands-Amsterdam, Hungary-Budapest" }, { "key" : "TRANSMISSION_WEB_UI", "value" : "transmission-web-control" } ], "exporting" : false, "id" : "3ea461c4454e8d0b0cfd1250ec598c91cb6cbb5cd24bdfb86ccf58592f1fa81b", "image" : "haugene/transmission-openvpn:latest", "is_ddsm" : false, "is_package" : false, "links" : [], "memory_limit" : 0, "name" : "haugene-transmission-openvpn2-copy", "network" : [ { "driver" : "bridge", "name" : "bridge" } ], "network_mode" : "bridge", "port_bindings" : [ { "container_port" : 8118, "host_port" : 8118, "type" : "tcp" }, { "container_port" : 9091, "host_port" : 9091, "type" : "tcp" } ], "privileged" : false, "shortcut" : { "enable_shortcut" : false, "enable_status_page" : false, "enable_web_page" : false, "web_page_url" : "" }, "use_host_network" : false, ] }

Current Behavior

On March 17, my docker container shutdown after detecting "Inactivity". When I tried to manually restart it, the VPN would not connect and would time out.

Expected Behavior

Should connect like it did previously.

How have you tried to solve the problem?

1) Checked changelog and found a cert change on the March 1st. I wonder if this is preventing the connection from re-establishing, but do not know how to debug since docker files are hidden in Synology DSM

Log output

Starting container with revision: 20877f1b168b6ff27fc58aeef40756572c562d47 Creating TUN device /dev/net/tun mknod: /dev/net/tun: File exists Using OpenVPN provider: SLICKVPNCORE Running with VPN_CONFIG_SOURCE auto No bundled config script found for SLICKVPNCORE. Defaulting to external config Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.zXb9azYx2y Extracting configs to /tmp/tmp.6ftpAxSaKW Found configs for SLICKVPNCORE in /tmp/tmp.6ftpAxSaKW/vpn-configs-contrib-main/openvpn/slickvpncore, will replace current content in /etc/openvpn/slickvpncore Cleanup: deleting /tmp/tmp.zXb9azYx2y and /tmp/tmp.6ftpAxSaKW 3 servers found in OPENVPN_CONFIG, Netherlands-Amsterdam chosen randomly Starting OpenVPN using config Netherlands-Amsterdam.ovpn Modifying /etc/openvpn/slickvpncore/Netherlands-Amsterdam.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 Setting OpenVPN credentials... Sun Mar 20 00:19:00 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021 Sun Mar 20 00:19:00 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Sun Mar 20 00:19:00 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Mar 20 00:19:00 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]96.118.22.105:443 Sun Mar 20 00:19:00 2022 Socket Buffers: R=[212992->212992] S=[212992->212992] Sun Mar 20 00:19:00 2022 UDP link local: (not bound) Sun Mar 20 00:19:00 2022 UDP link remote: [AF_INET]96.118.22.105:443 Sun Mar 20 00:20:00 2022 [UNDEF] Inactivity timeout (--ping-exit), exiting Sun Mar 20 00:20:00 2022 SIGTERM[soft,ping-exit] received, process exiting

Environment

- OS: Synology DSM 7.0.1-42218 Update 3
- Docker: 20.10.3-1239

Anything else?

No response

pkishino commented 2 years ago

suggest you try using CUSTOM provider option and specifying the updated files, if that works, submit a PR with the updated files to be merge in, thanks

philbar commented 2 years ago

Thanks for the suggestion @pkishino. I tried reverting the commit. It did not work. After a few hours of trying to resolve the issue, I decide to move to a more reliable VPN provider.