Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection keeps restarting (firewalled network) #180

Closed
AntouanK opened this issue Nov 24, 2016 · 12 comments
Closed

Connection keeps restarting (firewalled network) #180

AntouanK opened this issue Nov 24, 2016 · 12 comments

Comments

@AntouanK
Copy link

AntouanK commented Nov 24, 2016

Hi.

I'm using the docker image for more than a year now ( thanks for your work ).
Works perfectly fine, except when I go to work on big corporations where their networks are firewalled. ( I'm a contractor so I go to many different client sites )

I've tried to change the config to listen to TCP, and then have the docker container mapped from port 80 or 443 to 1194.
What happens ( I tried that at least in two different companies ) is that I can see in the logs that the connections are being reset and it's stuck in a loop of trying to connect.

I use tunnelblick and OSX macOS

I'll paste the logs here, in case it helps.
( actual IP masked with xxx.xxx.xxx )

*Tunnelblick: OS X 10.12.1; Tunnelblick 3.6.6 (build 4582); prior version 3.6.5 (build 4566)
2016-11-23 10:29:44 OpenVPN 2.3.11 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Aug 25 2016
2016-11-23 10:29:44 library versions: OpenSSL 1.0.2h  3 May 2016, LZO 2.09
2016-11-23 10:29:44 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2016-11-23 10:29:44 Need hold release from management interface, waiting...
2016-11-23 10:29:44 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2016-11-23 10:29:44 MANAGEMENT: CMD 'pid'
2016-11-23 10:29:44 MANAGEMENT: CMD 'state on'
2016-11-23 10:29:44 MANAGEMENT: CMD 'state'
2016-11-23 10:29:44 MANAGEMENT: CMD 'bytecount 1'
2016-11-23 10:29:44 MANAGEMENT: CMD 'hold release'
2016-11-23 10:29:44 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2016-11-23 10:29:44 Control Channel Authentication: tls-auth using INLINE static key file
2016-11-23 10:29:44 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-23 10:29:44 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-23 10:29:44 Socket Buffers: R=[131072->131072] S=[131072->131072]
2016-11-23 10:29:44 MANAGEMENT: >STATE:1479896984,RESOLVE,,,
2016-11-23 10:29:44 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.224:443 [nonblock]
2016-11-23 10:29:44 MANAGEMENT: >STATE:1479896984,TCP_CONNECT,,,
2016-11-23 10:29:44 *Tunnelblick: openvpnstart starting OpenVPN
2016-11-23 10:29:45 TCP connection established with [AF_INET]xxx.xxx.xxx.224:443
2016-11-23 10:29:45 TCPv4_CLIENT link local: [undef]
2016-11-23 10:29:45 TCPv4_CLIENT link remote: [AF_INET]xxx.xxx.xxx.224:443
2016-11-23 10:29:45 MANAGEMENT: >STATE:1479896985,WAIT,,,
2016-11-23 10:29:45 Connection reset, restarting [-1]

2016-11-23 10:29:45 SIGUSR1[soft,connection-reset] received, process restarting
2016-11-23 10:29:45 MANAGEMENT: >STATE:1479896985,RECONNECTING,connection-reset,,
2016-11-23 10:29:45 MANAGEMENT: CMD 'hold release'
2016-11-23 10:29:45 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2016-11-23 10:29:45 Control Channel Authentication: tls-auth using INLINE static key file
2016-11-23 10:29:45 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-23 10:29:45 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-23 10:29:45 Socket Buffers: R=[131072->131072] S=[131072->131072]
2016-11-23 10:29:45 MANAGEMENT: >STATE:1479896985,RESOLVE,,,
2016-11-23 10:29:45 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.224:443 [nonblock]
2016-11-23 10:29:45 MANAGEMENT: >STATE:1479896985,TCP_CONNECT,,,
2016-11-23 10:29:46 TCP connection established with [AF_INET]xxx.xxx.xxx.224:443
2016-11-23 10:29:46 TCPv4_CLIENT link local: [undef]
2016-11-23 10:29:46 TCPv4_CLIENT link remote: [AF_INET]xxx.xxx.xxx.224:443
2016-11-23 10:29:46 MANAGEMENT: >STATE:1479896986,WAIT,,,
2016-11-23 10:29:46 Connection reset, restarting [-1]

The part after

Connection reset, restarting [-1]

keeps looping again and again until I stop it.

Any idea on how to make it work?
My networks knowledge stops at port mapping and selecting the protocol :/

@AntouanK AntouanK changed the title Using openvpn from a firewalled network Connection keeps restarting (firewalled network) Nov 24, 2016
@kylemanna
Copy link
Owner

Few things could be happening. Since it seems to only occur when you're on client's sites, it's likely their firewall or NAT router is killing your connection and sending a reset.

For more information, try running the openvpn server with more verbosity, something like:

docker run ... kylemanna/openvpn ovpn_run --verb 5

And grab the OpenVPN server log file with:

docker logs <docker container hash or name>

If both the client and server get a connection reset at the same time and neither sent it, it's likely to be a corporate firewall complicating your situation.

@AntouanK
Copy link
Author

AntouanK commented Nov 25, 2016

@kylemanna
Here's the log from the openvpn container:

Fri Nov 25 09:55:58 2016 us=157180 MULTI: multi_create_instance called
Fri Nov 25 09:55:58 2016 us=157321 Re-using SSL/TLS context
Fri Nov 25 09:55:58 2016 us=157675 Control Channel MTU parms [ L:1543 D:1182 EF:68 EB:0 ET:0 EL:3 ]
Fri Nov 25 09:55:58 2016 us=157698 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:12 ET:0 EL:3 ]
Fri Nov 25 09:55:58 2016 us=157795 Local Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Fri Nov 25 09:55:58 2016 us=157805 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Fri Nov 25 09:55:58 2016 us=157843 Local Options hash (VER=V4): 'c413e92e'
Fri Nov 25 09:55:58 2016 us=157856 Expected Remote Options hash (VER=V4): 'd8421bb0'
Fri Nov 25 09:55:58 2016 us=157916 TCP connection established with [AF_INET]xxx.xx.x.199:32083
Fri Nov 25 09:55:58 2016 us=157931 TCPv4_SERVER link local: [undef]
Fri Nov 25 09:55:58 2016 us=157938 TCPv4_SERVER link remote: [AF_INET]xxx.xx.x.199:32083
Fri Nov 25 09:55:59 2016 us=227748 xxx.xx.x.199:32083 TLS: Initial packet from [AF_INET]xxx.xx.x.199:32083, sid=af8638e4 febec770

Fri Nov 25 09:55:59 2016 us=230988 xxx.xx.x.199:32083 Connection reset, restarting [-1]
Fri Nov 25 09:55:59 2016 us=231035 xxx.xx.x.199:32083 SIGUSR1[soft,connection-reset] received, client-instance restarting
Fri Nov 25 09:55:59 2016 us=231244 TCP/UDP: Closing socket
Fri Nov 25 09:55:59 2016 us=392578 MULTI: multi_create_instance called
Fri Nov 25 09:55:59 2016 us=392693 Re-using SSL/TLS context
Fri Nov 25 09:55:59 2016 us=392851 Control Channel MTU parms [ L:1543 D:1182 EF:68 EB:0 ET:0 EL:3 ]
Fri Nov 25 09:55:59 2016 us=392928 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:12 ET:0 EL:3 ]
Fri Nov 25 09:55:59 2016 us=392997 Local Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Fri Nov 25 09:55:59 2016 us=393009 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Fri Nov 25 09:55:59 2016 us=393042 Local Options hash (VER=V4): 'c413e92e'
Fri Nov 25 09:55:59 2016 us=393066 Expected Remote Options hash (VER=V4): 'd8421bb0'
Fri Nov 25 09:55:59 2016 us=393126 TCP connection established with [AF_INET]xxx.xx.x.199:32117
Fri Nov 25 09:55:59 2016 us=393144 TCPv4_SERVER link local: [undef]
Fri Nov 25 09:55:59 2016 us=393160 TCPv4_SERVER link remote: [AF_INET]xxx.xx.x.199:32117
Fri Nov 25 09:56:00 2016 us=459144 xxx.xx.x.199:32117 TLS: Initial packet from [AF_INET]xxx.xx.x.199:32117, sid=62113ccf 10c7c4a8

Fri Nov 25 09:56:00 2016 us=462203 xxx.xx.x.199:32117 Connection reset, restarting [-1]
Fri Nov 25 09:56:00 2016 us=462234 xxx.xx.x.199:32117 SIGUSR1[soft,connection-reset] received, client-instance restarting
Fri Nov 25 09:56:00 2016 us=462345 TCP/UDP: Closing socket
Fri Nov 25 09:56:00 2016 us=621345 MULTI: multi_create_instance called
Fri Nov 25 09:56:00 2016 us=621443 Re-using SSL/TLS context
Fri Nov 25 09:56:00 2016 us=621581 Control Channel MTU parms [ L:1543 D:1182 EF:68 EB:0 ET:0 EL:3 ]
Fri Nov 25 09:56:00 2016 us=621605 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:12 ET:0 EL:3 ]
Fri Nov 25 09:56:00 2016 us=621651 Local Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Fri Nov 25 09:56:00 2016 us=621661 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Fri Nov 25 09:56:00 2016 us=621687 Local Options hash (VER=V4): 'c413e92e'
Fri Nov 25 09:56:00 2016 us=621707 Expected Remote Options hash (VER=V4): 'd8421bb0'
Fri Nov 25 09:56:00 2016 us=621752 TCP connection established with [AF_INET]xxx.xx.x.199:32167
Fri Nov 25 09:56:00 2016 us=621772 TCPv4_SERVER link local: [undef]
Fri Nov 25 09:56:00 2016 us=621784 TCPv4_SERVER link remote: [AF_INET]xxx.xx.x.199:32167
Fri Nov 25 09:56:01 2016 us=692116 xxx.xx.x.199:32167 TLS: Initial packet from [AF_INET]xxx.xx.x.199:32167, sid=39cf58e7 9fe06834

Fri Nov 25 09:56:01 2016 us=694950 xxx.xx.x.199:32167 Connection reset, restarting [-1]
Fri Nov 25 09:56:01 2016 us=694984 xxx.xx.x.199:32167 SIGUSR1[soft,connection-reset] received, client-instance restarting
Fri Nov 25 09:56:01 2016 us=695072 TCP/UDP: Closing socket
Fri Nov 25 09:56:01 2016 us=875013 MULTI: multi_create_instance called
Fri Nov 25 09:56:01 2016 us=875089 Re-using SSL/TLS context

It goes on with the same segment between resets.

So what does that mean? Is there any way to avoid those resets?

corresponding logs from client, in case they are useful

2016-11-25 09:55:57 OpenVPN 2.3.11 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Aug 25 2016
2016-11-25 09:55:57 library versions: OpenSSL 1.0.2h  3 May 2016, LZO 2.09
2016-11-25 09:55:57 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2016-11-25 09:55:57 Need hold release from management interface, waiting...
2016-11-25 09:55:58 *Tunnelblick: Established communication with OpenVPN
2016-11-25 09:55:58 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2016-11-25 09:55:58 MANAGEMENT: CMD 'pid'
2016-11-25 09:55:58 MANAGEMENT: CMD 'state on'
2016-11-25 09:55:58 MANAGEMENT: CMD 'state'
2016-11-25 09:55:58 MANAGEMENT: CMD 'bytecount 1'
2016-11-25 09:55:58 MANAGEMENT: CMD 'hold release'
2016-11-25 09:55:58 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2016-11-25 09:55:58 Control Channel Authentication: tls-auth using INLINE static key file
2016-11-25 09:55:58 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-25 09:55:58 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-25 09:55:58 Socket Buffers: R=[131072->131072] S=[131072->131072]
2016-11-25 09:55:58 Attempting to establish TCP connection with [AF_INET]46.101.0.244:443 [nonblock]
2016-11-25 09:55:58 MANAGEMENT: >STATE:1480067758,TCP_CONNECT,,,
2016-11-25 09:55:59 TCP connection established with [AF_INET]46.101.0.244:443
2016-11-25 09:55:59 TCPv4_CLIENT link local: [undef]
2016-11-25 09:55:59 TCPv4_CLIENT link remote: [AF_INET]46.101.0.244:443
2016-11-25 09:55:59 MANAGEMENT: >STATE:1480067759,WAIT,,,

2016-11-25 09:55:59 Connection reset, restarting [-1]
2016-11-25 09:55:59 SIGUSR1[soft,connection-reset] received, process restarting
2016-11-25 09:55:59 MANAGEMENT: >STATE:1480067759,RECONNECTING,connection-reset,,
2016-11-25 09:55:59 *Tunnelblick: No 'reconnecting.sh' script to execute
2016-11-25 09:55:59 MANAGEMENT: CMD 'hold release'
2016-11-25 09:55:59 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2016-11-25 09:55:59 Control Channel Authentication: tls-auth using INLINE static key file
2016-11-25 09:55:59 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-25 09:55:59 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-25 09:55:59 Socket Buffers: R=[131072->131072] S=[131072->131072]
2016-11-25 09:55:59 Attempting to establish TCP connection with [AF_INET]46.101.0.244:443 [nonblock]
2016-11-25 09:55:59 MANAGEMENT: >STATE:1480067759,TCP_CONNECT,,,
2016-11-25 09:56:00 TCP connection established with [AF_INET]46.101.0.244:443
2016-11-25 09:56:00 TCPv4_CLIENT link local: [undef]
2016-11-25 09:56:00 TCPv4_CLIENT link remote: [AF_INET]46.101.0.244:443
2016-11-25 09:56:00 MANAGEMENT: >STATE:1480067760,WAIT,,,

2016-11-25 09:56:00 Connection reset, restarting [-1]
2016-11-25 09:56:00 SIGUSR1[soft,connection-reset] received, process restarting
2016-11-25 09:56:00 MANAGEMENT: >STATE:1480067760,RECONNECTING,connection-reset,,
2016-11-25 09:56:00 *Tunnelblick: No 'reconnecting.sh' script to execute
2016-11-25 09:56:00 MANAGEMENT: CMD 'hold release'
2016-11-25 09:56:00 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2016-11-25 09:56:00 Control Channel Authentication: tls-auth using INLINE static key file
2016-11-25 09:56:00 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-25 09:56:00 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2016-11-25 09:56:00 Socket Buffers: R=[131072->131072] S=[131072->131072]
2016-11-25 09:56:00 Attempting to establish TCP connection with [AF_INET]46.101.0.244:443 [nonblock]
2016-11-25 09:56:00 MANAGEMENT: >STATE:1480067760,TCP_CONNECT,,,
2016-11-25 09:56:01 TCP connection established with [AF_INET]46.101.0.244:443
2016-11-25 09:56:01 TCPv4_CLIENT link local: [undef]
2016-11-25 09:56:01 TCPv4_CLIENT link remote: [AF_INET]46.101.0.244:443
2016-11-25 09:56:01 MANAGEMENT: >STATE:1480067761,WAIT,,,

2016-11-25 09:56:01 Connection reset, restarting [-1]
2016-11-25 09:56:01 SIGUSR1[soft,connection-reset] received, process restarting
2016-11-25 09:56:01 MANAGEMENT: >STATE:1480067761,RECONNECTING,connection-reset,,

@kylemanna
Copy link
Owner

I'm guessing that since they both client and server appear to see resets at the same time and neither appear to send them, that the firewall is sending them. This is supported by the same server and client working on a different network.

You might try confirming this isn't related to openvpn by running opensshd on port 443/tcp and connecting to it with an ssh client. I suspect the ssh connection will reset as well, running ssh -vvv while testing will give you more insight. This will confirm the suspicion that running non HTTPS traffic over port 443 is going to always cause problems.

Another option might be to try different ports or udp to try and dodge the firewall rules. There maybe some stateful inspection on port 443/tcp expecting to see the beginning of HTTPs negotiation, and when there isn't any it kills it. I'd encourage you to try another port if any are open. Probably need to do some port scanning of a remote host you own with a a few ports open to test. As always, using udp if possible is recommended. :)

@AntouanK
Copy link
Author

Thanks for the help.

So any quick way to check ports that are open and accept UDP?
Something like nmap maybe?

@kylemanna
Copy link
Owner

Not that I know of off the top of my head. Could try setting up a openvpn container and using iptables port redirects to redirect a ton of ports to your server and check if any work.

@AntouanK
Copy link
Author

@kylemanna
I've tried to check for open ports.
With UDP, all of them seem to work.
For example, I tried netcat from both sides for port 1001.

client -> server ( with openvpn container running and listening on 1001 )

> $ nc -vz -u -w 2 178.62.124.133 1001
found 0 associations
found 1 connections:
     1:	flags=82<CONNECTED,PREFERRED>
	outif (null)
	src 10.56.2.220 port 51525
	dst 178.62.124.133 port 1001
	rank info not available

Connection to 178.62.124.133 port 1001 [udp/*] succeeded!

from server -> client

root@docker:~# nc -vz -u -w 2 xx.xx.xx.199 1001
Connection to xx.xx.xx.199 1001 port [udp/customs] succeeded!

Still openvpn never gets to connect and process keeps restarting.

@kylemanna
Copy link
Owner

Perhaps the firewall is detecting OpenVPN. I've seen similar things by the great firewall of China. ExpressVPN has a modified OpenVPN client and server that managed to succeed. That's all I can think of other then trying to reach the network admins on the network with issues.

@kylemanna
Copy link
Owner

Closing due to no updates in a few months.

@2ge
Copy link

2ge commented Sep 7, 2017

I bump into this topic after I got
2017-09-07 11:31:31 SIGUSR1[soft,connection-reset] received, process restarting

In my situation it was, that openVPN was connected twice. One on the one computer, and other one (which keeps disconnecting) on another one. It was set up like that on server. Maybe this will helps somebody - you can not have two connections to server.

@vgezer
Copy link

vgezer commented Sep 2, 2019

I bump into this topic after I got
2017-09-07 11:31:31 SIGUSR1[soft,connection-reset] received, process restarting

In my situation it was, that openVPN was connected twice. One on the one computer, and other one (which keeps disconnecting) on another one. It was set up like that on server. Maybe this will helps somebody - you can not have two connections to server.

What a lifesaver!

@bronger
Copy link

bronger commented Sep 29, 2019

[…]

In my situation it was, that openVPN was connected twice. One on the one computer, and other one (which keeps disconnecting) on another one. It was set up like that on server. Maybe this will helps somebody - you can not have two connections to server.

Just to be sure: An OpenVPN server does only allow one connection at a time, no matter how configured?

@gr4ssi
Copy link

gr4ssi commented Feb 26, 2021

Just to be sure: An OpenVPN server does only allow one connection at a time, no matter how configured?

I've got two simultaneous connections all day (TCP/443) and no issues. (Phone/PC)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants