-
Kios
- OpenVpn Newbie
- Posts: 3
- Joined: Wed Mar 13, 2019 8:33 am
read TCP_CLIENT: Unknown error (code=10060)
Hi all,
Wed Mar 13 09:29:05 2019 read TCP_CLIENT: Unknown error (code=10060)
Wed Mar 13 09:29:05 2019 Connection reset, restarting [-1]
Wed Mar 13 09:29:05 2019 SIGUSR1[soft,connection-reset] received, process restarting
Wed Mar 13 09:29:10 2019 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.
I’m getting this error randomly (every few minutes or something like that). It’s really bothering me a quite bit. On my old workstation everything works fine, but on the new one I’m faced with this issue. Because I’m using VMware Workstation app, it disconnects me every time, and I need to log in :S, that is really pain in the ass.
I’ve googled for ages, but didn’t find any soultions that could help me.
Any help would be appricated,
thanks.
-
novaflash
- OpenVPN Inc.
- Posts: 1072
- Joined: Fri Apr 13, 2012 8:43 pm
Re: read TCP_CLIENT: Unknown error (code=10060)
Post
by novaflash » Wed Mar 13, 2019 8:43 am
Look for Windows socket error code 10060.
In short, your connection is getting disrupted, and OpenVPN then can’t do its job.
I’m still alive, just posting under the openvpn_inc alias now as part of a larger group.
-
Kios
- OpenVpn Newbie
- Posts: 3
- Joined: Wed Mar 13, 2019 8:33 am
Re: read TCP_CLIENT: Unknown error (code=10060)
Post
by Kios » Wed Mar 13, 2019 1:17 pm
Thanks. To be honest I’ve googled 10060, bud didn’t find anything useful. I’ve found this https://www.youtube.com/watch?v=dknUbTRZsCY , but didn’t help.
And Sometimes I can see this message appearing when the connection is reconnected.
Edit:
Wed Mar 13 15:07:06 2019 [xxx.xxx.xxx.xxx] Inactivity timeout (—ping-restart), restarting
Wed Mar 13 15:07:06 2019 SIGUSR1[soft,ping-restart] received, process restarting
Wed Mar 13 15:07:11 2019 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.
Last edited by Kios on Wed Mar 13, 2019 2:10 pm, edited 1 time in total.
-
novaflash
- OpenVPN Inc.
- Posts: 1072
- Joined: Fri Apr 13, 2012 8:43 pm
Re: read TCP_CLIENT: Unknown error (code=10060)
Post
by novaflash » Wed Mar 13, 2019 1:59 pm
Try literally googling for: Windows socket error code 10060. Guaranteed to have results that are relevant.
I’m still alive, just posting under the openvpn_inc alias now as part of a larger group.
-
Kios
- OpenVpn Newbie
- Posts: 3
- Joined: Wed Mar 13, 2019 8:33 am
Re: read TCP_CLIENT: Unknown error (code=10060)
Post
by Kios » Thu Mar 14, 2019 7:51 am
novaflash wrote: ↑
Wed Mar 13, 2019 1:59 pm
Try literally googling for: Windows socket error code 10060. Guaranteed to have results that are relevant.
I’ve did that and only two things that I’ve found are:
https://kb.globalscape.com/Knowledgebas … 10384.aspx -> regarding the regedit entery that doesn’t exist on win10
And the second one is the internetProperties -> Lan options that is by default ok with me.
There are some recommendation regarding the firewall I’ve created inbound/outbound rules for port 1194 but didn’t helped.
I’m having feeling that I’m running in the circle whole time :S
-
novaflash
- OpenVPN Inc.
- Posts: 1072
- Joined: Fri Apr 13, 2012 8:43 pm
Re: read TCP_CLIENT: Unknown error (code=10060)
Post
by novaflash » Thu Mar 14, 2019 10:36 am
Yeah. So, we can’t really help you either. This error is an error reported by the operating system’s methods of communicating with the outside world. And they’re saying that the connection was lost. This has nothing to do with an OpenVPN problem. This is a connection problem. Like a broken Internet connection or such. If it was an OpenVPN error, then we could have given you some suggestions, but this is an error coming from the OS.
I’m still alive, just posting under the openvpn_inc alias now as part of a larger group.
-
PegLeg
- OpenVpn Newbie
- Posts: 1
- Joined: Thu Oct 13, 2022 10:14 am
Windows socket error code 10060 FIX
Post
by PegLeg » Thu Oct 13, 2022 10:16 am
Hi,
Midweek windows released an update to windows 10,
A security/cumulative update, I allowed windows to automatically update and install it.
The update is KB5018410
This update sends Open VNP round in circles with a “Windows socket error code 10060”
I have removed the update and now I can log back in to open VNP.
Should you be experiencing this problem.
1: open SETTINGS from the windows start key in lower left corner of desktop
2: select UPDATES & SECURITY
3: Select VIEW UPDATES in the centre of the ecreen
4: select UNINSTALL UPDATES
5: highlight update KB5018410 only
6: press UNINSTALL
7: wait for it to complete and restart the pc.
I’ve been using your script a lot last 5 months maybe, and even made a fork without encryption and compression to fully utilize the potential speed. The problem is that possibly after a corporate firewall update about a week ago I could not connect as usual using my fork, as it turns out even the latest version of your script is not able to connect. Both UDP and TCP do not connect properly. I know that some people have already come across similar stuff, but maybe you could suggest a solution for me. Could it possibly be a certificate issue? Thank you
UDP:
Sun Jun 10 11:57:11 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sun Jun 10 11:57:11 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Jun 10 11:57:11 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Sun Jun 10 11:57:11 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Jun 10 11:57:11 2018 Need hold release from management interface, waiting…
Sun Jun 10 11:57:11 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘state on’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘log all on’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘echo all on’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘bytecount 5’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘hold off’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘hold release’
Sun Jun 10 11:57:11 2018 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 11:57:11 2018 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 11:57:11 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:57:11 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 11:57:11 2018 UDP link local: (not bound)
Sun Jun 10 11:57:11 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:57:11 2018 MANAGEMENT: >STATE:1528610231,WAIT,,,,,,
Sun Jun 10 11:58:11 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 11:58:11 2018 TLS Error: TLS handshake failed
Sun Jun 10 11:58:11 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 11:58:11 2018 MANAGEMENT: >STATE:1528610291,RECONNECTING,tls-error,,,,,
Sun Jun 10 11:58:11 2018 Restart pause, 5 second(s)
Sun Jun 10 11:58:16 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:58:16 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 11:58:16 2018 UDP link local: (not bound)
Sun Jun 10 11:58:16 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:58:16 2018 MANAGEMENT: >STATE:1528610296,WAIT,,,,,,
Sun Jun 10 11:59:16 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 11:59:16 2018 TLS Error: TLS handshake failed
Sun Jun 10 11:59:16 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 11:59:16 2018 MANAGEMENT: >STATE:1528610356,RECONNECTING,tls-error,,,,,
Sun Jun 10 11:59:16 2018 Restart pause, 5 second(s)
Sun Jun 10 11:59:21 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:59:21 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 11:59:21 2018 UDP link local: (not bound)
Sun Jun 10 11:59:21 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:59:21 2018 MANAGEMENT: >STATE:1528610361,WAIT,,,,,,
Sun Jun 10 12:00:21 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:00:21 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:00:21 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:00:21 2018 MANAGEMENT: >STATE:1528610421,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:00:21 2018 Restart pause, 5 second(s)
Sun Jun 10 12:00:26 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:00:26 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:00:26 2018 UDP link local: (not bound)
Sun Jun 10 12:00:26 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:00:26 2018 MANAGEMENT: >STATE:1528610426,WAIT,,,,,,
Sun Jun 10 12:01:26 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:01:26 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:01:26 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:01:26 2018 MANAGEMENT: >STATE:1528610486,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:01:26 2018 Restart pause, 5 second(s)
Sun Jun 10 12:01:31 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:01:31 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:01:31 2018 UDP link local: (not bound)
Sun Jun 10 12:01:31 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:01:31 2018 MANAGEMENT: >STATE:1528610491,WAIT,,,,,,
Sun Jun 10 12:02:32 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:02:32 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:02:32 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:02:32 2018 MANAGEMENT: >STATE:1528610552,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:02:32 2018 Restart pause, 10 second(s)
Sun Jun 10 12:02:42 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:02:42 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:02:42 2018 UDP link local: (not bound)
Sun Jun 10 12:02:42 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:02:42 2018 MANAGEMENT: >STATE:1528610562,WAIT,,,,,,
Sun Jun 10 12:03:42 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:03:42 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:03:42 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:03:42 2018 MANAGEMENT: >STATE:1528610622,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:03:42 2018 Restart pause, 20 second(s)
Sun Jun 10 12:04:02 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:04:02 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:04:02 2018 UDP link local: (not bound)
Sun Jun 10 12:04:02 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:04:02 2018 MANAGEMENT: >STATE:1528610642,WAIT,,,,,,
Sun Jun 10 12:05:02 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:05:02 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:05:02 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:05:02 2018 MANAGEMENT: >STATE:1528610702,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:05:02 2018 Restart pause, 40 second(s)
Sun Jun 10 12:05:42 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:05:42 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:05:42 2018 UDP link local: (not bound)
Sun Jun 10 12:05:42 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:05:42 2018 MANAGEMENT: >STATE:1528610742,WAIT,,,,,,
Sun Jun 10 12:06:42 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:06:42 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:06:42 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:06:42 2018 MANAGEMENT: >STATE:1528610802,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:06:42 2018 Restart pause, 80 second(s)
UDP config:
client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 165.227.143.71 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3
TCP:
Sun Jun 10 23:16:47 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sun Jun 10 23:16:47 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Jun 10 23:16:47 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Sun Jun 10 23:16:47 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Jun 10 23:16:47 2018 Need hold release from management interface, waiting…
Sun Jun 10 23:16:48 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘state on’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘log all on’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘echo all on’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘bytecount 5’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘hold off’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘hold release’
Sun Jun 10 23:16:48 2018 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 23:16:48 2018 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 23:16:48 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:16:48 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:16:48 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:16:48 2018 MANAGEMENT: >STATE:1528651008,TCP_CONNECT,,,,,,
Sun Jun 10 23:16:49 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:16:49 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:16:49 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:16:49 2018 MANAGEMENT: >STATE:1528651009,WAIT,,,,,,
Sun Jun 10 23:17:13 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:17:13 2018 Connection reset, restarting [-1]
Sun Jun 10 23:17:13 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:17:13 2018 MANAGEMENT: >STATE:1528651033,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:17:13 2018 Restart pause, 5 second(s)
Sun Jun 10 23:17:18 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:18 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:17:18 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:17:18 2018 MANAGEMENT: >STATE:1528651038,TCP_CONNECT,,,,,,
Sun Jun 10 23:17:19 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:19 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:17:19 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:19 2018 MANAGEMENT: >STATE:1528651039,WAIT,,,,,,
Sun Jun 10 23:17:41 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:17:41 2018 Connection reset, restarting [-1]
Sun Jun 10 23:17:41 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:17:41 2018 MANAGEMENT: >STATE:1528651061,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:17:41 2018 Restart pause, 5 second(s)
Sun Jun 10 23:17:46 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:46 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:17:46 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:17:46 2018 MANAGEMENT: >STATE:1528651066,TCP_CONNECT,,,,,,
Sun Jun 10 23:17:47 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:47 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:17:47 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:47 2018 MANAGEMENT: >STATE:1528651067,WAIT,,,,,,
Sun Jun 10 23:18:08 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:18:08 2018 Connection reset, restarting [-1]
Sun Jun 10 23:18:08 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:18:08 2018 MANAGEMENT: >STATE:1528651088,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:18:08 2018 Restart pause, 5 second(s)
Sun Jun 10 23:18:13 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:13 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:18:13 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:18:13 2018 MANAGEMENT: >STATE:1528651093,TCP_CONNECT,,,,,,
Sun Jun 10 23:18:14 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:14 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:18:14 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:14 2018 MANAGEMENT: >STATE:1528651094,WAIT,,,,,,
Sun Jun 10 23:18:35 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:18:35 2018 Connection reset, restarting [-1]
Sun Jun 10 23:18:35 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:18:35 2018 MANAGEMENT: >STATE:1528651115,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:18:35 2018 Restart pause, 5 second(s)
Sun Jun 10 23:18:40 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:40 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:18:40 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:18:40 2018 MANAGEMENT: >STATE:1528651120,TCP_CONNECT,,,,,,
Sun Jun 10 23:18:41 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:41 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:18:41 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:41 2018 MANAGEMENT: >STATE:1528651121,WAIT,,,,,,
Sun Jun 10 23:19:02 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:19:02 2018 Connection reset, restarting [-1]
Sun Jun 10 23:19:02 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:19:02 2018 MANAGEMENT: >STATE:1528651142,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:19:02 2018 Restart pause, 10 second(s)
Sun Jun 10 23:19:12 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:12 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:19:12 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:19:12 2018 MANAGEMENT: >STATE:1528651152,TCP_CONNECT,,,,,,
Sun Jun 10 23:19:13 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:13 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:19:13 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:13 2018 MANAGEMENT: >STATE:1528651153,WAIT,,,,,,
Sun Jun 10 23:19:35 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:19:35 2018 Connection reset, restarting [-1]
Sun Jun 10 23:19:35 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:19:35 2018 MANAGEMENT: >STATE:1528651175,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:19:35 2018 Restart pause, 20 second(s)
Sun Jun 10 23:19:55 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:55 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:19:55 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:19:55 2018 MANAGEMENT: >STATE:1528651195,TCP_CONNECT,,,,,,
Sun Jun 10 23:19:56 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:56 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:19:56 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:56 2018 MANAGEMENT: >STATE:1528651196,WAIT,,,,,,
Sun Jun 10 23:20:17 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:20:17 2018 Connection reset, restarting [-1]
Sun Jun 10 23:20:17 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:20:17 2018 MANAGEMENT: >STATE:1528651217,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:20:17 2018 Restart pause, 40 second(s)
Sun Jun 10 23:20:57 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:20:57 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:20:57 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:20:57 2018 MANAGEMENT: >STATE:1528651257,TCP_CONNECT,,,,,,
Sun Jun 10 23:20:58 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:20:58 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:20:58 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:20:58 2018 MANAGEMENT: >STATE:1528651258,WAIT,,,,,,
Sun Jun 10 23:21:20 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:21:20 2018 Connection reset, restarting [-1]
Sun Jun 10 23:21:20 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:21:20 2018 MANAGEMENT: >STATE:1528651280,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:21:20 2018 Restart pause, 80 second(s)
Sun Jun 10 23:22:40 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:22:40 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:22:40 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:22:40 2018 MANAGEMENT: >STATE:1528651360,TCP_CONNECT,,,,,,
Sun Jun 10 23:22:41 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:22:41 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:22:41 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:22:41 2018 MANAGEMENT: >STATE:1528651361,WAIT,,,,,,
Sun Jun 10 23:23:03 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:23:03 2018 Connection reset, restarting [-1]
Sun Jun 10 23:23:03 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:23:03 2018 MANAGEMENT: >STATE:1528651383,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:23:03 2018 Restart pause, 160 second(s)
TCP config:
client
dev tun
proto tcp
sndbuf 0
rcvbuf 0
remote 46.101.235.206 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3
Wi-CAT LLC
Wireless Comprehensive Advanced Technology. Build your network now.
Вы должны войти, чтобы создавать сообщения и темы.
(так и не повторилось) OpenVPN и ошибка 10060
Вчера переехал со старого кинетика на 3.0.12.RU.10122020 / AP-Gateway(Router) / MT7621 CPU, MT7615DN 2T2R DBDC, 1000FDX. Подключение PurePPPoE, Justlan. Настольный комп по LAN гигабит. И сразу же стали происходить реконнекты клиента OpenVPN. Оговорюсь сразу, работаю через этого клиента не меньше пяти лет, сервер в моём городе, почти весь 2020 год клиент не выключался. Ни разу не видел такой причины разрыва соединения. И как только сменил роутер, началось. Через произвольные интервалы времени (иногда 10 минут, иногда 3 часа) происходит переконнект с сервером. В логе OpenVPN примерно следующее:
Thu Dec 10 18:34:56 2020 Initialization Sequence Completed Thu Dec 10 18:56:40 2020 read TCP_CLIENT: Unknown error (code=10060) Thu Dec 10 18:56:40 2020 Connection reset, restarting [-1] Thu Dec 10 18:56:40 2020 SIGUSR1[soft,connection-reset] received, process restarting
Я на сервере не единственный клиент, но реконнекты там только у меня, остальные 50+ клиентов работают без сбоев.
Запускал в фоне пинги до гугла (8.8.8.8) и до собственно сервера с впн, в момент потери соединения пинги не тормозят, как были 22 мс и 1 мс соответственно, так и идут как вкопанные.
В логах роутера в эти моменты ничего нет.
Есть идеи, куда копать и что попробовать? Может какие-то расширенные логи есть? PPPoE посмотреть, например…
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Опять вангу звать? Ок. Ванга грит keepalive… Больше ничего не говорит.
Что это за причина мне неведомо, но предполагаю (и ванга согласна) что за 7600с ни одного пакета по соединению не прошло и оно было вынесено из контрака как мёртврое (что верно ибо нафиг память на него тратить ещё). Что бы этого не происходило есть механизи keepalive в т.ч. в openvpn.
Lexus@lexus
20 СообщенийАвтор темы
Не уточнил сразу: на компе работал mstsc-клиент, внутри которого по rdp я воочию наблюдаю последствия таких реконнектов в виде фриза на минуту. То есть по туннелю трафик был, была активная работа. Да и ping 10 был в конфиге ovpn
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Ни я не ванга ничего не можем сказать на эту тему. Все предположеия которые можно сделать из данных в репорте даны выше. Увы, я не автор openvpn и даже не автор винды что бы по какому-то адовому error code (всяко винда возвращает) понять что ж там по факту случилось.
Роутер ничего не знает о вашем openvpn для него все соединения это udp или tcp, ну если нет под них конкретного ALG. Под openvpn ессно его нет и быть не может.
Как стандарт openvpn ISO то же не принимался. Т.е. RFC нет. Все остальные TCP прикладухи работают нормально? Ну значит и дебажить нужно начинать со стороны самого openvpn чего ему не нравиться. А к нам приходить уже с конкретикой.
Так что ой. Ничего кроме вышесказанного мне сказать не чего.
P.S. 2 раза намекнул уже что данных мало и даже базовые вещи указанные в теме рядом на тему того какие данные по минимуму нужно предоставлять не выполнены. Хотя они врятли помогут пока не будет понятно что там openvpn думает и что это за ошибка такая и чего значит. Вы думаете я зря к Ванге обращаюсь. =)))
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Ванга тут ещё подсказывает, грит может NAT Offload вырубить. Ибо всякую нестандартщину таки временами при работающем оффлоаде может подплющивать. Хотя куда стандартнее TCP… =)
В общем не в курсе. Может вы там в netdiag в произвольное время clear cache тыкаете. Или провайдер решил пошалить (рядом есть темы где «началось» со сменой роутера, а оказалось совпало с работами на стороне провайдера. По описанию формата «началось», к сожалени даже лучшие европейские медиумы ничего сказать не в силах. Особенно в полночь. 
P.S. Пинги в фоне не прерываются значит в логах PPPOE смотерть нечего т.е. сессия не теряется. Запсутите параллельно mtr и помониторьте потери. Запросто может оказаться что где-то на промежуточном хопе в моменты отвалов лавинообразно возникают потери. Чудес не бывает. Но что бы я мог помочь, мне нужны данные, особенно когда речь идёт о сервисах которые я лично не юзаю и о них мне ничего неизвестно. Тогда нужны данные начиная с версии сервера на обратном конце, всех настроек и сервера и клиента и т.д. и т.п. Правда это в любом случае вопросы то наверное уже мимо, и роутер тут очень сильно сбоку… Но mtr в отличии от пинга (интервал только поменьше поставьте) возможно подскажет в чём беда и где.
Lexus@lexus
20 СообщенийАвтор темы
Да я понимаю, что это рвётся в первую очередь соединение операционки. И OpenVPN после этого ничего поделать уже не может.
У меня была надежда, что можно какие-нибудь детальные логи включить посмотреть, может это у провайдера что-то не честно. Кстати, можете себе плашку Квант-Телекома (Джастлан их бренд) повесить на страницу операторов интернета в ЦФО 
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Ой эти все плашки. =))) Лучше бы они в тест бы железки бы запросили, глядишь какие-нить нюансы бы выяснились.
P.S. см о mtr выше, вот он может попутно что-то подсказать. Роутер чего, он занатил и выплюнул пакет (ну грубо говоря), если tcp и не получил ack плюнул ещё несколько раз и забил. Он транзитный узел. Хоть циска будь хоть кто угодно. Диагностировать на его уровне особенно нечего как минимум до понимания чего не нравиться клиенту или серверу. Даже Шерлоку нужно понимать от чего отталкиваться. А тут как в том мультике «-Ничего не понимаю… —Аналогично!» =)))
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Да забыл. Размер пакета тоже и пингу и mtr поставить ну пусть 1400, на мелких пакетах потери можно и не заметить.
Lexus@lexus
20 СообщенийАвтор темы
Вчера погонял mtr на штатных настройках. В момент обрыва соединения каких-то отклонений в динамике показателей не заметил. Сегодня увеличил размер с 64 до 1400, качественно ничего не изменилось. Картинка за вчера
Вечером слушал онлайн-радио (не из-под VPN), один раз оно тоже прервалось одновременно с обрывом соединения OpenVPN, хотя были и такие реконнекты, когда радио не затыкалось.
Сегодня выключил NAT offload и теперь жду. Пока мало времени прошло
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Спрашивал у товарища сегодня не видит ли он у себя чего подобного. Грит нет и порекомендовал стартовать openvpn с ключиками -remote peer и –ping 5 если ходит поверх другого туннеля с NAT (pppoe тоже подпадает под это).
Lexus@lexus
20 СообщенийАвтор темы
-remote peer и –ping 5
Эти ключики есть в конфиге.
С выключенным NAT offload вот уже 9 часов нет ни одного реконнекта.
А вот зацепка: я попробовал задействовать файрвол на роутере. Просто переключил в Enable пункт MAC/IP/Port Filtering и нажал Apply, даже не вводя никакие правила. И тут же знакомая ошибка 10060 и реконнект. Делаю Disable и Apply — опять реконнект
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Цитата: Lexus от 11/12/2020, 23:20
-remote peer и –ping 5
Эти ключики есть в конфиге.
С выключенным NAT offload вот уже 9 часов нет ни одного реконнекта.
Плохо. Пробуйте отключать оффлоады не полностью а перейти только в софтварный и только в хардварный. Выяснить нужно какой оффлоад приводит к тому что openvpn подплющивает.
Скорее всего это будет хардварный. Который увы из себя представляет чёрный ящик и максимум что от текущего состояния с ним можно сделать это исключать выборочно трафик из него. Т.к. openvpn может работать по любому порту и использовать как tcp так и udp то придётся видимо делать крутилку индивидуально.
А вот зацепка: я попробовал задействовать файрвол на роутере. Просто переключил в Enable пункт MAC/IP/Port Filtering и нажал Apply, даже не вводя никакие правила. И тут же знакомая ошибка 10060 и реконнект. Делаю Disable и Apply — опять реконнект
Это не зацепка, а штатное поведение. Что бы правила применялись не когда-нить потом а сразу, при любых манипуляциях на странице фаервола после нажатия применить сбрасываются все стэйты контрака и текущие соединения порвуться.
В общем пробуйте описанное выше. Отключать оффлоады зло, надо определить какой оффлоад, дальше подумаем как красиво сделать возможность обхода проблемы совместимости с ним.
Lexus@lexus
20 СообщенийАвтор темы
Цитата: sfstudio от 12/12/2020, 08:13
Плохо. Пробуйте отключать оффлоады не полностью а перейти только в софтварный и только в хардварный. Выяснить нужно какой оффлоад приводит к тому что openvpn подплющивает.
По умолчанию был включен Complex. Когда я стал отключать оффлоад, то попробовал сначала перейти на рекомендуемый для PPPoE режим Hardware. В течение часа в нём тоже произошел реконнект и я просто поставил Disable. Software вчера не пробовал, запущу сегодня. Отпишу тогда
Upd: 7 часов, полёт стабильный
Lexus@lexus
20 СообщенийАвтор темы
В общем, на софтовом оффлоаде проблем нет, как и на выключенном
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Ок. Сейчас соберётся 3.0.14 проверим на ней. Если будет повторяться скажу что ещё нужно будет проверить и сделаем тады крутилку что бы можно было по портам выкусывать трафик из PPE т.к. порт зарание неизвестен увы.
ООочень всё это всё же странно, есть догадка почему такое может быть, но скорее из области фантастики т.к. приводило бы к проблемам не только с openvpn а вообще с любыми TCP. Скорее всё же что-то там такое openvpn пытается такое в заголовках tcp чудить что блок PPE аппаратно переварить не в силах. А значит только выкусывать.
Попробую у себя развернуть повторить на всякий. Но не факт что повториться.
Lexus@lexus
20 СообщенийАвтор темы
Цитата: sfstudio от 14/12/2020, 08:44
Ок. Сейчас соберётся 3.0.14 проверим на ней. Если будет повторяться скажу что ещё нужно будет проверить и сделаем тады крутилку что бы можно было по портам выкусывать трафик из PPE т.к. порт зарание неизвестен увы.
Накатил 3.0.14, сделал сброс и минимальные настройки: OpenVPN разорвался через полтора часа.
приводило бы к проблемам не только с openvpn а вообще с любыми TC
Когда я онлайн-радио слушал, воспроизведение пропадало одновременно с некоторыми разрывами OpenVPN. Причем без обновления страницы радио воспроизведение само не восстанавливалось.
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Что за радио? Openvpn у меня вот прямо сейчас работает и ни единого разрыва.
Жду когда порвется.
Может хоть на радио повторю…
Lexus@lexus
20 СообщенийАвтор темы
Цитата: sfstudio от 14/12/2020, 14:24
Что за радио? Openvpn у меня вот прямо сейчас работает и ни единого разрыва.
101.ru
Сейчас одновременно с RDP по OpenVPN, запущенному на компьютере с LAN, я полтора часа проводил видеоконференцию с помощью Jitsi meet с андроид-телефона по Wi-Fi. Не интересовался, что там за протокол, но соединение Jitsi не рвалось, а OpenVPN за это время раза 4 реконнектился. Сервер в обоих случаях один и тот же. Либо протокол более устойчив к обрывам сессии, либо дело в том, что Jitsi работал поверх WLAN (и напрямую без VPN, сам по себе), а OpenVPN поднят на LAN-интерфейсе
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Или еще 100500 причин. Хоть загадайся пока у меня повторяемости нет.
Как и за 10ток лет не было массовых жалоб.
Это веяния каких-то изменений либо на стороне приложений либо на стороне ос которые видимо и приводят к какому-то хитрому поведению ppe.
Вот это в разы вероятнее.
Бум пробовать разобраться.
Ок с радио проверю.
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Радио играет уже более 12 часов через OpenVPN работающий через 2шт DUO-G каскадом по LAN. Проблемы ни первой ни второй не вижу ;(
Ось какая на клиентах?
Единственная догадка которая приходит в голову это то что таки регулярно есть потери где-то по пути. В случае с PPE отсутствует практически буферизация т.е. нет шансов что передатчик задетектит потери и перепошлёт пакет и обработка таких ситуаций ложиться на клиентскую ось. В софт режиме из-за избыточной буферизации проблему может быть просто не видно или она ооочень сильно отодвигается во времени.
Косвенно об этом может говорить отсутсвие проблемы через wifi т.к. там сам драйвер тасует пакеты, занимается агрегацией и т.д. т.е. имеет очень жирный буфер (иначе скорость по радио была бы мягко сказать), в то время как по LAN для сессий обслуживаемых PPE выплёвывается буквально сразу из него напрямую в железо минуя всю программную обработку включая буферизацию.
Но это всё же только догадка.
Попробуем локализовать траблу и придумать что-то.
Для этого нужно для начала выяснить.
В обоих ли направлениях оффлоад приводит к такому поведению. Для этого используем тулзу hw_nat
Only Speed UP (0=Upstream, 1=Downstream, 2=Bi-Direction) flow Ex: hw_nat -Z 1
После полной загрузки командуем hw_nat -Z 1 т.е. переключаем в режим оффлоада только в download path. Проверяем. Затем так же только с hw_nat -Z 0.
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Эти настройки не сохраняются т.е. работают до релоада драйвера PPE.
Lexus@lexus
20 СообщенийАвтор темы
Радио играет уже более 12 часов через OpenVPN
У меня стрим радио был запущен параллельно туннелю, но не в нём. И иногда прерывались оба соединения, а иногда только впн.
Ось какая на клиентах?
Домашние компьютеры на вин10 2004. Сегодня полдня работал с другого домашнего компа (воткнут в соседний порт LAN) — те же проблемы.
Для этого нужно для начала выяснить. В обоих ли направлениях оффлоад приводит к такому поведению
Да, в обоих. И после hw_nat -Z 1, и после hw_nat -Z 0 наблюдаются реконнекты
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Ок буду искать винду. Не могу на рабочем ПК выделить ей столько рабочего времени на повторение. Под *nix (разных) не повторяется ни в туннеле ни сбоку.
Lexus@lexus
20 СообщенийАвтор темы
Запустил OpenVPN до того же сервера под Ubuntu 20.04 (внутри WSL2 виндов, хост — всё та же win10), которая выходит в свет через VirtualBox-сетевой адаптер в режиме NAT. За 8 часов ни одного реконнекта
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
Вывод? Tcp стэк винды чудит или возможно какой-нить встроенный в антивирус фаер плющит что и приводит к чудесам на стороне ppe.
Wsl2 нынче тупо виртуалка
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
В общем на чистой 10тке (специально водрузил на старый ноут свежую систему) так же не увидел проблемы.
Что стоит из антивирусов и т.п. в системе? Вот почти уверен где-то там собака зарыта. Надо добиться повторяемости у меня что бы придумать как обойти безболезненно. Ну или хотя бы понять кому репортить.
Lexus@lexus
20 СообщенийАвтор темы
Что стоит из антивирусов и т.п. в системе?
Kaspersky Anti-Virus 21.2. Встроенный в вин10 дефендер отключен настолько, насколько это возможно. Ну офис, браузеры и игры тут вроде влиять не должны, а больше и нет ничего особенного.
Вот момент обрыва соединения: пакет 13628
sfstudio@sfstudio
2 340 Сообщений
Wi-CAT
С касперским были траблы в RTNL из-за чего с goahead спозли на nginx. Он время от времени решал дропать часть ACK при этом UI роутера начинал страшно тормозить, ибо goahead не посылал следующую порцию данных.
Решением было добавление в исключения адреса роутера у касперского. Отключение его не помогало никак. Либо адрес в исключения либо полное удаление.
Дампы трафика тут ни чем не помогут (особенно в виде скринов). Мне нужна повторяемость. Буду пробовать с касперским чего делать. Надеюсь у них есть бесплатная версия. Ибо тырить софт не приучен.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Hello!
I use OpenVPN to access my customers and my job environment when I am not at the office.
It worked fine until I did a Windows Update, one thing to note is that everyone elses OpenVPN works.. I am the only one though who have this kind of computer model, HP EliteBook Folio 1040 G2.
When I try connect to OpenVPN I get this error in the log:
Tue Mar 05 09:57:48 2019 Initialization Sequence Completed
Tue Mar 05 09:58:03 2019 read TCP_CLIENT: Unknown error (code=10060)
Tue Mar 05 09:58:03 2019 Connection reset, restarting [-1]
Tue Mar 05 09:58:03 2019 SIGUSR1[soft,connection-reset] received, process restarting
Tue Mar 05 09:58:08 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]212.116.72.203:8080
Tue Mar 05 09:58:08 2019 Attempting to establish TCP connection with [AF_INET]212.116.72.203:8080 [nonblock]
And my internet connection goes off.
This seems to be a problem other people have too. I saw an old thread from three months ago
OpenVPN works fine over LAN line but over Wifi disconnects immediately from OpenVPN
Here they say you should disable «HP LAN/WLAN/WWAN Switching UWP Service». I did that and after that my Wi-fi connection didnt go off and I didnt get the Code=10060 error. But the OpenVPN just kept going on and off with this error repeating in an endless loop:
Tue Mar 05 10:01:14 2019 Initialization Sequence Completed
Tue Mar 05 10:01:20 2019 Connection reset, restarting [0]
Tue Mar 05 10:01:20 2019 SIGUSR1[soft,connection-reset] received, process restarting
Tue Mar 05 10:01:25 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]212.116.72.203:8080
Tue Mar 05 10:01:25 2019 Attempting to establish TCP connection with [AF_INET]212.116.72.203:8080 [nonblock]
Tue Mar 05 10:01:26 2019 TCP connection established with [AF_INET]212.116.72.203:8080
Tue Mar 05 10:01:26 2019 TCP_CLIENT link local (bound): [AF_INET][undef]:0
Tue Mar 05 10:01:26 2019 TCP_CLIENT link remote: [AF_INET]212.116.72.203:8080
Tue Mar 05 10:01:26 2019 [vpn.optivasys.se] Peer Connection Initiated with [AF_INET]212.116.72.203:8080
Tue Mar 05 10:01:28 2019 Preserving previous TUN/TAP instance: Ethernet 2
Tue Mar 05 10:01:28 2019 Initialization Sequence Completed
Tue Mar 05 10:01:34 2019 Connection reset, restarting [0]
Tue Mar 05 10:01:34 2019 SIGUSR1[soft,connection-reset] received, process restarting
I have also tried the Powermanagement solution at the bottom of the thread with no result.
Yesterday I did a reset on my computer and the OpenVPN worked, but as soon as I did these five Window updates:
Quality Updates:
2019-02 Cumulative Update for Windows 10 Version 1809 for x64-based Systems (KB4482887) (2)
2019-01 Cumulative Update for .Net Framwork 3.5 and 4.7.2 for Windows 10 Version 1809 for x64 (KB4480056)
2019-02 Cumulative Update for .Net Framwork 3.5 and 4.7.2 for Windows 10 Version 1809 for x64 (KB4486553)
Definition Updates:
Definition Update for Windows Defender Antivirus — KB2267602 (Definition 1.289.403.0
Update for Windows Defender Antivirus antimalware platform — KB4052623 (Version 4.18.1902.2)
Other Updates:
Windows Malicious Software Removal Tool x64 — February 2019 (KB890830)
The OpenVPN stoped working and I got the code=10060 error… I have no clue which on of these is the problem but I still want my computer to have the latest updates.
PLEASE HELP! I need OpenVPN to work…
Best regards, Fredrik
Posted by robert k wild 2022-05-24T15:42:11Z
hi all,
getting this error on openvpn client connecting to an openvpn server
the funny thing is the client can open up a telnet session to the server, so they can hit the tcp port, the openvpn server is using tcp not udp
the client is in cairo so they block vpn especially openvpn, even using a different port doesnt help
can i put a new line in the client config or the server config?
anyone else have suggestions
thanks,
rob
5 Replies
-
Using a reverse proxy maybe on port 443? It’d be an interesting try since port 443 will be harder to detect that it’s openvpn traffic. I found this blog that might help you out.
https://blog.jarrousse.org/getting-openvpn-and-nginx-to-share-port-443/ Opens a new window
Was this post helpful?
thumb_up
thumb_down
-
Will I be a able to sshin via SSH tunnel if the openvpn server is on a sophos xgs firewall
Was this post helpful?
thumb_up
thumb_down
-
Can the users create an ssh tunnel to the Fw and then run up openvpn client
Was this post helpful?
thumb_up
thumb_down
-
What is your end goal? I think if they’re able to ssh into the firewall they wouldn’t need a VPN too? Maybe the approach could be a different style of VPN like ipsec with L2TP or something like that? Some more details of what you are trying to do will help.
Was this post helpful?
thumb_up
thumb_down
-
My end goal is for Cairo staff to VPN in on the sophos xgs Fw as ATM they cant as Egypt block openvpn or any VPN come to think of it
Was this post helpful?
thumb_up
thumb_down
Read these next…
Snap! — No-Password Logins, Solar Powered Water Filter, Glitch in the Matrix?
Spiceworks Originals
Your daily dose of tech news, in brief.
Welcome to the Snap!
Flashback: February 9, 1996: Introduction of the Bandai Pippin (Read more HERE.)
Bonus Flashback: February 9, 1990: Galileo Probe does a Venus Flyby (Read more HERE.)
You nee…
Roku TV being used as Wallboard Issues
Hardware
Helping someone out at their shop. They have 4 large Roku screens and 2 laptops with dual HDMI ports for video. They are viewing static website business dashboards and PowerPoint. At first all 4 screens connected to wireless, worked for a while but with a…
Charging for SSO
Security
We have SSO set up with around 5 or 6 solution providers via our M365. Not one of them charges for this, they just sent us the documentation.I identified another online service in use by one of our departments which would benefit from using SSO for staff …
Spark! Pro series — 9th February 2023
Spiceworks Originals
Today in History: America meets the Beatles on “The Ed Sullivan Show”
At approximately 8:12 p.m. Eastern time, Sunday, February 9, 1964, The Ed Sullivan Show returned from a commercial (for Anacin pain reliever), and there was Ed Sullivan standing …
Green Brand Rep Wrap-Up: January 2023
Spiceworks Originals
Source Opens a new window Opens a new windowHi, y’all — Chad here. A while back, we used to feature the top posts from our brand reps (aka “Green Gals/Guys/et. al.) in a weekly or monthly wrap-up post. I can’t specifically recall which, as that was ap…
