Open cnzhx opened 6 years ago
Then, I directly installed Streisand inside the GCP instance with "LocalHost (advanced)" option. All seems working except the OpenVPN through Stunnel one (I am still trying other options).
One idea: Have you verified port 993
is accessible? Normally when Streisand creates the GCP instance for you it also sets up the correct Google Cloud Network with the required firewall rules for the services enabled. If you created the instance yourself manually and then installed Streisand to it, the GCP network rules may not match and port 993
for stunnel may be blocked.
Mar 07 20:39:02 nm-openvpn[2489]: TCP: connect to [AF_INET]127.0.0.1:41194 failed: Connection refused
From your OpenSUSE Tumbleweed logs: It looks to me like you don't have stunnel
running and configured on 127.0.0.1:41194
and so OpenVPN isn't able to connect.
Hi, @cpu , thank you for your response.
One idea: Have you verified port 993 is accessible?
I manually added the firewall rules to allow port 993 for 0.0.0.0/0 .
From your OpenSUSE Tumbleweed logs: It looks to me like you don't have stunnel running and configured on 127.0.0.1:41194 and so OpenVPN isn't able to connect.
I checked and found stunnel is running, like this,
● stunnel4.service - LSB: Start or stop stunnel 4.x (SSL tunnel for network daemons)
Loaded: loaded (/etc/init.d/stunnel4; bad; vendor preset: enabled)
Active: active (running) since Wed 2018-03-07 15:17:42 UTC; 1 weeks 6 days ago
Docs: man:systemd-sysv-generator(8)
Tasks: 1
Memory: 2.0M
CPU: 10.378s
CGroup: /system.slice/stunnel4.service
└─8785 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf
And journal says,
Mar 20 23:08:41 s001 sslh[1230]: connection from s001.c.s001-20180302.internal:49130
Mar 20 23:09:11 s001 stunnel[8785]: LOG3[38379]: SSL_accept: Peer suddenly disconnected
Mar 20 23:09:11 s001 sslh[1230]: connection from s001.c.s001-20180302.internal:49146
Mar 20 23:09:41 s001 stunnel[8785]: LOG3[38380]: SSL_accept: Peer suddenly disconnected
Mar 20 23:09:41 s001 sslh[1230]: connection from s001.c.s001-20180302.internal:49158
Mar 20 23:10:11 s001 stunnel[8785]: LOG3[38381]: SSL_accept: Peer suddenly disconnected
Mar 20 23:10:11 s001 sslh[1230]: connection from s001.c.s001-20180302.internal:49176
Mar 20 23:10:41 s001 stunnel[8785]: LOG3[38382]: SSL_accept: Peer suddenly disconnected
Mar 20 23:10:41 s001 sslh[1230]: connection from s001.c.s001-20180302.internal:49188
Note that these logs appear in pair and in an interval of 30 seconds.
But I have no client connecting to this server by OpenVPN at the moment. So it looks to me that sslh and stunnel have some glitches between them. But I do not know how to debug it.
Hi @cnzhx - Thanks for the follow-up information. It does seem like there's something broken here that merits further investigation. I'll try to set up a stunnel
configuration of my own to debug alongside in the next few days. Thanks for your patience.
Hi, @cpu , thank you very much for looking into this. I am looking forward to your good news :-)
:wave: apologies for the long delay in getting back to this issue.
I set up a brand new DigitalOcean instance using the tip of master configured to have OpenVPN and Stunnel enabled. I followed the Android setup instructions using OpenVPN for Android and SSLDroid.
Initially the connection would fail to establish and the server-side stunnel logs included lines like the following:
stunnel[623]: LOG3[1]: s_connect: connect ::1:636: Connection refused (111)
The IPv6 localhost address looked strange so I tried changing /etc/stunnel/stunnel.conf
on the Streisand server to have connect = 127.0.0.1:636
instead of connect = 636
.
After restarting stunnel (systemctl restart stunnel
) and redialing the OpenVPN & Stunnel connections from my phone the "Connection refused' errors in the server side stunnel log went away. :tada: I put a PR out with this fix here: https://github.com/StreisandEffect/streisand/pull/1311
Unfortunately it still doesn't work for me :sob: OpenVPN halts at the "authenticating" phase. In the server-side Stunnel logs I see numerous SSL_read
errors:
LOG3[14]: SSL_read: Connection reset by peer (104)
I'm going to increase the logging verbosity and try with a Linux desktop next instead of the Android client to see if that provides some more insight. I'm not clear yet who is the "peer" in this error message: the other end of the stunnel connection, or the OpenVPN server.
Hi @cpu , thanks a lot for your continue investigation into this issue. Sorry that I could not help on solving this.
It seems you read a different error from mine. On my server, stunnel keeps (every 30 seconds) saying,
stunnel[14716]: LOG3[3]: SSL_accept: Peer suddenly disconnected
But I have not been trying to connect at the time.
I totally have no idea what's going on there.
Without diving to much into it, that error is usually what would happen when I suspected a state actor detected and severed my VPN connection. Are you trying to use openvpn + stunnel where a state actor may be at play? If so do you have anyone who can try connecting from outside that?
On Sun, Apr 29, 2018, 06:19 H Zeng notifications@github.com wrote:
Hi @cpu https://github.com/cpu , thanks a lot for your continue investigation into this issue. Sorry that I could not help on solving this.
It seems you read a different error from mine. On my server, stunnel keeps (every 30 seconds) saying,
stunnel[14716]: LOG3[3]: SSL_accept: Peer suddenly disconnected
But I have not been trying to connect at the time.
I totally have no idea what's going on there.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/StreisandEffect/discussions/issues/106#issuecomment-385209260, or mute the thread https://github.com/notifications/unsubscribe-auth/ACE5KMqayTwf5yYY-pgHpe1NgPg5LMeEks5ttOrfgaJpZM4ShI26 .
Hi @nickolasclarke , I am not sure I understood the "state actor" correctly. Do you mean I need to check the server error messages when it is connected through stunnel from another PC other than the one I am using to monitor the server through SSH?
No I mean is the government or another 3rd party in between you and your server actively attempting to detect and cut VPN connections to your knowledge? I read this a bit closer after I sent the message and saw that you are having success with openVPN w/out stunnel, so I'd guess that the answer is no.
On Tue, May 1, 2018 at 12:17 AM H Zeng notifications@github.com wrote:
Hi @nickolasclarke https://github.com/nickolasclarke , I am not sure I understood the "state actor" correctly. Do you mean I need to check the server error messages when it is connected through stunnel from another PC other than the one I am using to monitor the server through SSH?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/StreisandEffect/discussions/issues/106#issuecomment-385449298, or mute the thread https://github.com/notifications/unsubscribe-auth/ACE5KMTMYQRjtLQ5noDCqCfs5tkqVq9gks5ttzkPgaJpZM4ShI26 .
Yes, you're right. My VPN connection is currently not blocked, I think.
Hi, I think I got something new about this. Maybe systems upgrades changed the situation.
Now, my system seems able to connect through stunnel. The problem is I cannot browse internet through the connection.
Here is the log of nm-openvpn (tried to connect twice, both successful),
-- Reboot --
May 02 16:19:44 ostp nm-openvpn[30117]: OpenVPN 2.4.3 x86_64-suse-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [
May 02 16:19:44 ostp nm-openvpn[30117]: library versions: OpenSSL 1.1.0h-fips 27 Mar 2018, LZO 2.10
May 02 16:19:44 ostp nm-openvpn[30117]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/ho
May 02 16:19:44 ostp nm-openvpn[30117]: NOTE: the current --script-security setting may allow this configuration to call user-defined s
May 02 16:19:44 ostp nm-openvpn[30117]: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:41194
May 02 16:19:44 ostp nm-openvpn[30117]: Attempting to establish TCP connection with [AF_INET]127.0.0.1:41194 [nonblock]
May 02 16:19:44 ostp nm-openvpn[30117]: TCP connection established with [AF_INET]127.0.0.1:41194
May 02 16:19:44 ostp nm-openvpn[30117]: TCP_CLIENT link local: (not bound)
May 02 16:19:44 ostp nm-openvpn[30117]: TCP_CLIENT link remote: [AF_INET]127.0.0.1:41194
May 02 16:19:44 ostp nm-openvpn[30117]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
May 02 16:19:46 ostp nm-openvpn[30117]: [you-decorate-deny] Peer Connection Initiated with [AF_INET]127.0.0.1:41194
May 02 16:19:47 ostp nm-openvpn[30117]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: block-
May 02 16:19:47 ostp nm-openvpn[30117]: TUN/TAP device tun0 opened
May 02 16:19:47 ostp nm-openvpn[30117]: /usr/lib/nm-openvpn-service-openvpn-helper --debug 0 30114 --bus-name org.freedesktop.NetworkMa
May 02 16:19:47 ostp nm-openvpn[30117]: GID set to nm-openvpn
May 02 16:19:47 ostp nm-openvpn[30117]: UID set to nm-openvpn
May 02 16:19:47 ostp nm-openvpn[30117]: Initialization Sequence Completed
May 02 16:20:00 ostp nm-openvpn[30117]: Connection reset, restarting [-1]
May 02 16:20:00 ostp nm-openvpn[30117]: SIGUSR1[soft,connection-reset] received, process restarting
May 02 16:20:05 ostp nm-openvpn[30117]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/ho
May 02 16:20:05 ostp nm-openvpn[30117]: NOTE: the current --script-security setting may allow this configuration to call user-defined s
May 02 16:20:05 ostp nm-openvpn[30117]: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:41194
May 02 16:20:05 ostp nm-openvpn[30117]: Attempting to establish TCP connection with [AF_INET]127.0.0.1:41194 [nonblock]
May 02 16:20:05 ostp nm-openvpn[30117]: TCP connection established with [AF_INET]127.0.0.1:41194
May 02 16:20:05 ostp nm-openvpn[30117]: TCP_CLIENT link local: (not bound)
May 02 16:20:05 ostp nm-openvpn[30117]: TCP_CLIENT link remote: [AF_INET]127.0.0.1:41194
May 02 16:20:15 ostp nm-openvpn[30117]: Connection reset, restarting [-1]
May 02 16:20:15 ostp nm-openvpn[30117]: SIGUSR1[soft,connection-reset] received, process restarting
May 02 16:20:20 ostp nm-openvpn[30117]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/ho
May 02 16:20:20 ostp nm-openvpn[30117]: NOTE: the current --script-security setting may allow this configuration to call user-defined s
May 02 16:20:20 ostp nm-openvpn[30117]: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:41194
May 02 16:20:20 ostp nm-openvpn[30117]: Attempting to establish TCP connection with [AF_INET]127.0.0.1:41194 [nonblock]
May 02 16:20:20 ostp nm-openvpn[30117]: TCP connection established with [AF_INET]127.0.0.1:41194
May 02 16:20:20 ostp nm-openvpn[30117]: TCP_CLIENT link local: (not bound)
May 02 16:20:20 ostp nm-openvpn[30117]: TCP_CLIENT link remote: [AF_INET]127.0.0.1:41194
May 02 16:20:30 ostp nm-openvpn[30117]: Connection reset, restarting [-1]
May 02 16:20:30 ostp nm-openvpn[30117]: SIGUSR1[soft,connection-reset] received, process restarting
May 02 16:20:35 ostp nm-openvpn[30117]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/ho
May 02 16:20:35 ostp nm-openvpn[30117]: NOTE: the current --script-security setting may allow this configuration to call user-defined s
May 02 16:20:35 ostp nm-openvpn[30117]: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:41194
May 02 16:20:35 ostp nm-openvpn[30117]: Attempting to establish TCP connection with [AF_INET]127.0.0.1:41194 [nonblock]
May 02 16:20:35 ostp nm-openvpn[30117]: TCP connection established with [AF_INET]127.0.0.1:41194
May 02 16:20:35 ostp nm-openvpn[30117]: TCP_CLIENT link local: (not bound)
May 02 16:20:35 ostp nm-openvpn[30117]: TCP_CLIENT link remote: [AF_INET]127.0.0.1:41194
May 02 16:20:41 ostp nm-openvpn[30117]: event_wait : Interrupted system call (code=4)
May 02 16:20:41 ostp nm-openvpn[30117]: SIGTERM[hard,] received, process exiting
lines 22-49/49 (END)
And here is the stunnel log from the server in the corresponding time range,
May 02 15:15:31 s001 stunnel[14716]: LOG3[10670]: SSL_accept: Peer suddenly disconnected
May 02 15:16:01 s001 stunnel[14716]: LOG3[10671]: SSL_accept: Peer suddenly disconnected
May 02 15:16:31 s001 stunnel[14716]: LOG3[10672]: SSL_accept: Peer suddenly disconnected
May 02 15:17:01 s001 stunnel[14716]: LOG3[10673]: SSL_accept: Peer suddenly disconnected
May 02 15:17:31 s001 stunnel[14716]: LOG3[10674]: SSL_accept: Peer suddenly disconnected
May 02 15:18:01 s001 stunnel[14716]: LOG3[10675]: SSL_accept: Peer suddenly disconnected
May 02 15:18:31 s001 stunnel[14716]: LOG3[10676]: SSL_accept: Peer suddenly disconnected
May 02 15:19:01 s001 stunnel[14716]: LOG3[10677]: SSL_accept: Peer suddenly disconnected
May 02 15:19:31 s001 stunnel[14716]: LOG3[10678]: SSL_accept: Peer suddenly disconnected
May 02 15:19:46 s001 stunnel[14716]: LOG3[10667]: SSL_read: Connection reset by peer (104)
May 02 15:20:01 s001 stunnel[14716]: LOG3[10680]: SSL_accept: Peer suddenly disconnected
May 02 15:20:31 s001 stunnel[14716]: LOG3[10681]: SSL_accept: Peer suddenly disconnected
May 02 15:21:01 s001 stunnel[14716]: LOG3[10682]: SSL_accept: Peer suddenly disconnected
May 02 15:21:11 s001 stunnel[14716]: LOG3[10679]: SSL_read: Connection reset by peer (104)
May 02 15:21:31 s001 stunnel[14716]: LOG3[10683]: SSL_accept: Peer suddenly disconnected
May 02 15:22:02 s001 stunnel[14716]: LOG3[10684]: SSL_accept: Peer suddenly disconnected
May 02 15:22:32 s001 stunnel[14716]: LOG3[10685]: SSL_accept: Peer suddenly disconnected
May 02 15:23:02 s001 stunnel[14716]: LOG3[10686]: SSL_accept: Peer suddenly disconnected
May 02 15:23:32 s001 stunnel[14716]: LOG3[10687]: SSL_accept: Peer suddenly disconnected
May 02 15:24:02 s001 stunnel[14716]: LOG3[10688]: SSL_accept: Peer suddenly disconnected
May 02 15:24:32 s001 stunnel[14716]: LOG3[10689]: SSL_accept: Peer suddenly disconnected
May 02 15:25:02 s001 stunnel[14716]: LOG3[10690]: SSL_accept: Peer suddenly disconnected
May 02 15:25:32 s001 stunnel[14716]: LOG3[10691]: SSL_accept: Peer suddenly disconnected
Hello everyone,
I need some help to spot the problem with OpenVPN over stunnel. I cannot connect by this method either from Android phone or in Linux desktop. I checked all the relative clients including SSLDroid, OpenVPN in both devices but could not identify the problem. Only message pertaining this problem I could get is the LOG information of Stunnel on the server. Shown by
journalctl
on the server, following messages occurs every 30 seconds.Here are some details about my implementation.
Several days ago, I tried to install the Streisand on Google cloud platform (GCP) with a newly created instance. The OS chosen is Ubuntu 16.04. This system is very new to me. I only have two years experience with openSUSE.
Firstly, Streisand failed when I tried to install remotely from an newly installed openSUSE Tumbleweed VM. It said it requires
libcloud<=1.17.0
but obviously I had installedlibcloud
according to the instructions of Streisand. Then, I directly installed Streisand inside the GCP instance with "LocalHost (advanced)" option. All seems working except the OpenVPN through Stunnel one (I am still trying other options).I use SSLDroid on my phone with OpenVPN for Android. OpenVPN log shows it failed a lot of times then waited longer to try another round. It still cannot connect now.
Then, I tried OpenVPN in my laptop with openSUSE Tumbleweed using the
*_stunnel.ovpn
profile, which is imported into my system with NetworkManager in KDE Plasma desktop environment. I still cannot connect.journalctl -r
gives following log,But I can connect using OpvenVPN-sslh and normal OpenVPN profile.
I guest the problem is with Stunnel. But I do not know how to solve it.
Any suggestion is welcomed.