search

haugene / vpn-configs-contrib

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

Torguard VPN - TLS Error: TLS key negotiation failed to occur within 60 seconds #50

Closed SteveW25561 closed 3 years ago

SteveW25561 commented 3 years ago

Before creating this issue I have:

REQUIRED

Container version & last working release

**Required, problem occurs in :** `````` *If possible, last working version:* `````` ### Describe the problem ``` TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed SIGUSR1[soft,tls-error] received, process restarting Restart pause, 5 second(s) ``` **REQUIRED** ```txt Can't seem to connect to the VPN server, thus Transmission never starts ``` ### Describe the steps you have tried to solve the problem **REQUIRED** ```txt Rebuilt container Tried DNS override ENV variables Tried CREATE_TUN_DEVICE=true ``` ### Add your docker run command or docker-compose file or env details **REQUIRED** ```txt version: '3.3' services: transmission-openvpn: cap_add: - NET_ADMIN volumes: - '/Volumes/Expansion:/volume1/Expansion' - '/Volumes/Synology/Fresh/Transmission/completed:/downloads' - '/Volumes/Synology/Fresh/Transmission:/data' - '/Volumes/Synology:/volume1/Synology' environment: - OPENVPN_USERNAME=username - OPENVPN_PASSWORD=password - OPENVPN_PROVIDER=TORGUARD - LOCAL_NETWORK=192.168.0.0/23 - OVERRIDE_DNS_1=8.8.8.8 - OVERRIDE_DNS_2=8.8.4.4 logging: driver: json-file options: max-size: 10m ports: - '9091:9091' image: haugene/transmission-openvpn ``` ### Logs **REQUIRED** ```txt transmission-openvpn_1 | Starting container with revision: 73ec516cc246972289c7b96ffa88c81e037fe364 transmission-openvpn_1 | One or more OVERRIDE_DNS addresses found. Will use them to overwrite /etc/resolv.conf transmission-openvpn_1 | Creating TUN device /dev/net/tun transmission-openvpn_1 | Using OpenVPN provider: TORGUARD transmission-openvpn_1 | No VPN configuration provided. Using default. transmission-openvpn_1 | Setting OpenVPN credentials... transmission-openvpn_1 | adding route to local network 192.168.0.0/23 via 172.21.0.1 dev eth0 transmission-openvpn_1 | 2021-07-23 05:15:15 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6 transmission-openvpn_1 | 2021-07-23 05:15:15 OpenVPN 2.5.2 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 4 2021 transmission-openvpn_1 | 2021-07-23 05:15:15 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10 transmission-openvpn_1 | 2021-07-23 05:15:15 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts transmission-openvpn_1 | 2021-07-23 05:15:15 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication transmission-openvpn_1 | 2021-07-23 05:15:15 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication transmission-openvpn_1 | 2021-07-23 05:15:15 TCP/UDP: Preserving recently used remote address: [AF_INET]206.217.216.10:1912 transmission-openvpn_1 | 2021-07-23 05:15:15 Socket Buffers: R=[212992->425984] S=[212992->425984] transmission-openvpn_1 | 2021-07-23 05:15:15 UDP link local: (not bound) transmission-openvpn_1 | 2021-07-23 05:15:15 UDP link remote: [AF_INET]206.217.216.10:1912 transmission-openvpn_1 | 2021-07-23 05:16:15 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) transmission-openvpn_1 | 2021-07-23 05:16:15 TLS Error: TLS handshake failed transmission-openvpn_1 | 2021-07-23 05:16:15 SIGUSR1[soft,tls-error] received, process restarting transmission-openvpn_1 | 2021-07-23 05:16:15 Restart pause, 5 second(s) transmission-openvpn_1 | 2021-07-23 05:16:20 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts transmission-openvpn_1 | 2021-07-23 05:16:20 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication transmission-openvpn_1 | 2021-07-23 05:16:20 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication transmission-openvpn_1 | 2021-07-23 05:16:20 TCP/UDP: Preserving recently used remote address: [AF_INET]206.217.216.23:1912 transmission-openvpn_1 | 2021-07-23 05:16:20 Socket Buffers: R=[212992->425984] S=[212992->425984] transmission-openvpn_1 | 2021-07-23 05:16:20 UDP link local: (not bound) transmission-openvpn_1 | 2021-07-23 05:16:20 UDP link remote: [AF_INET]206.217.216.23:1912 ^CGracefully stopping... (press Ctrl+C again to force) ``` ### Host system **REQUIRED** ```txt Running MacOS (Intel), Docker (Docker Desktop 2.5.1) Local network is 192.168.0.0/23 ```
github-actions[bot] commented 3 years ago

@SteveW25561: hello! :wave:

This issue is being automatically closed because it does not follow the issue template. If you edit and follow the template properly by filling it in completely the issue will be re-opened

github-actions[bot] commented 3 years ago

@SteveW25561: hello! :wave:

This issue is being automatically closed because it does not follow the issue template. If you edit and follow the template properly by filling it in completely the issue will be re-opened

rutravis commented 3 years ago

I'm not clear per the git-hub actions. Was this closed and reopened, or is it closed? I'm a Torguard user and I get exactly the same responses in my log files. After retrying 3-5 times, it will eventually connect.

Log file from failed container startup:

Starting container with revision: 73ec516cc246972289c7b96ffa88c81e037fe364

Creating TUN device /dev/net/tun

Using OpenVPN provider: TORGUARD

Starting OpenVPN using config USA-NEW-JERSEY.ovpn

Setting OpenVPN credentials...

adding route to local network 192.168.1.0/24 via 172.18.0.1 dev eth2

2021-08-12 17:47:49 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6

2021-08-12 17:47:49 OpenVPN 2.5.2 aarch64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 4 2021

2021-08-12 17:47:49 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10

2021-08-12 17:47:49 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-08-12 17:47:49 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

2021-08-12 17:47:49 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

2021-08-12 17:47:49 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1912

2021-08-12 17:47:49 Socket Buffers: R=[212992->425984] S=[212992->425984]

2021-08-12 17:47:49 UDP link local: (not bound)

2021-08-12 17:47:49 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1912

2021-08-12 17:48:49 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

2021-08-12 17:48:49 TLS Error: TLS handshake failed

2021-08-12 17:48:49 SIGUSR1[soft,tls-error] received, process restarting

2021-08-12 17:48:49 Restart pause, 5 second(s)

2021-08-12 17:48:54 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-08-12 17:48:54 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

2021-08-12 17:48:54 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

2021-08-12 17:48:54 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1912

2021-08-12 17:48:54 Socket Buffers: R=[212992->425984] S=[212992->425984]

2021-08-12 17:48:54 UDP link local: (not bound)

2021-08-12 17:48:54 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx1912

2021-08-12 17:49:54 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

2021-08-12 17:49:54 TLS Error: TLS handshake failed

2021-08-12 17:49:54 SIGUSR1[soft,tls-error] received, process restarting

2021-08-12 17:49:54 Restart pause, 5 second(s)

2021-08-12 17:49:59 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-08-12 17:49:59 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

2021-08-12 17:49:59 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

2021-08-12 17:49:59 TCP/UDP: Preserving recently used remote address: [AF_INET]1xxx.xxx.xxx.xxx:1912

2021-08-12 17:49:59 Socket Buffers: R=[212992->425984] S=[212992->425984]

2021-08-12 17:49:59 UDP link local: (not bound)

2021-08-12 17:49:59 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1912

2021-08-12 17:50:54 event_wait : Interrupted system call (code=4)

2021-08-12 17:50:54 SIGTERM[hard,] received, process exiting

pkishino commented 3 years ago

Both of these look like issues with the vpn server.. does this occur with any server or only specific ones? Might want to contact support for the provider and check if the configs are correct

hbt commented 3 years ago

I fixed it by running "updateConfigs.sh" and changing the "proto udp" to "proto tcp" ref https://github.com/hbt/docker-transmission-openvpn/blob/master/openvpn/torguard/updateConfigs.sh

This started happening about a week ago and intensified late this week. It would take several minutes and multiple retries to get a connection.

So far, switching to tcp fixes the issue for me. Although I still use "UDP" for the torguard openvpn GUI client and it works fine.

rutravis commented 3 years ago

I cloned your config and am now trying to create a docker image from it to run on my docker swarm

tcamargo commented 3 years ago

Getting the same error on ATL servers since yesterday.

rutravis commented 3 years ago

I did what hbt did and it is working great. Fast connection and is very stable. Haven't done a WAN speed test.

elementdc5 commented 3 years ago

Could someone please point me in the right direction on how exactly I run "updateConfigs.sh" and change it to "proto tcp"

I'm a noob on this stuff

chris948 commented 3 years ago

Could someone please point me in the right direction on how exactly I run "updateConfigs.sh" and change it to "proto tcp"

I'm a noob on this stuff

I was able to locate the updateConfigs.sh in the /etc/openvpn folder. So in my case I use portainer to console into the container, and cd /etc/openvpn then ./updateConfigs.sh. YMMV.

Thankfully I didn't have to edit the opevnvpn config to 'proto tcp' I was still trying to figure out which one I would actually edit when it started working after the updateConfigs.

pkishino commented 3 years ago

can someone please check if switching to dev branch fixes this and gets the correct new configs?

Jonathan34 commented 3 years ago

Had the same issue - it may be the dedicated IP you are using from torguard is deprecated? There was an email sent with subject: "IMPORTANT - Config Breaking Change", I attach it below. I had to get a new ip and request the port forward then it works fine.

TorGuard Network Upgrades and IP Refresh

TorGuard is one of the most reliable and rock-solid VPNs on the market, but we never stop trying to do better. Our network team is currently upgrading hardware on all US locations and refreshing all IP ranges to provide improved services in these areas. Servers will have larger ports for better speeds, providing increased capacity that can handle twice as much load as before. TorGuard users will instantly notice a faster/smoother experience in these data centres.

Dedicated IP's

As we are refreshing all IP address ranges in these locations we would advise that anyone with a Dedicated IP on the legacy LA IP network that you upgrade to the new improved LA IP range as soon as possible. To take advantage of this IP refresh simply submit a support ticket and request an IP change. TorGuard’s legacy LA location will be discontinued in the next few weeks.

If you have a port forward on this address range simply re-request it on the newer range from within the client area.

This change will not affect streaming or residential IP ranges and only applies to our legacy LA IP ranges. Dallas, Miami and NJ will also undergo upgrades in the following weeks and we will keep you updated on when those new servers will become available.
tcamargo commented 3 years ago

I changed my dedicated IP to the new range but it didn’t work. Had to enable tcp to get it back online.

pkishino commented 3 years ago

please verify this against the 4.0 latest release to make sure it's still an issue