1 |
Michael wrote: |
2 |
> On Wednesday, 8 March 2023 18:30:55 GMT Dale wrote: |
3 |
> |
4 |
>> It starts at about 13:54. It seems to try to reconnect but can't. I got this |
5 |
>> by using tail -n and then grep openvpn on the end. |
6 |
>> |
7 |
>> |
8 |
>> Mar 1 13:53:32 fireball openvpn[27908]: |
9 |
>> [us-hou-v029.prod.surfshark.com] Inactivity timeout (--ping-restart), |
10 |
>> restarting |
11 |
>> Mar 1 13:53:32 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500 |
12 |
>> 1584 10.8.8.9 255.255.255.0 restart |
13 |
>> Mar 1 13:53:32 fireball openvpn[27908]: SIGUSR1[soft,ping-restart] |
14 |
>> received, process restarting |
15 |
>> Mar 1 13:53:32 fireball openvpn[27908]: Restart pause, 5 second(s) |
16 |
>> Mar 1 13:53:37 fireball openvpn[27908]: NOTE: the current |
17 |
>> --script-security setting may allow this configuration to call |
18 |
>> user-defined scripts |
19 |
>> Mar 1 13:53:37 fireball openvpn[27908]: Outgoing Control Channel |
20 |
>> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication |
21 |
>> Mar 1 13:53:37 fireball openvpn[27908]: Incoming Control Channel |
22 |
>> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication |
23 |
>> Mar 1 13:53:37 fireball openvpn[27908]: TCP/UDP: Preserving recently |
24 |
>> used remote address: [AF_INET]37.19.221.71:1194 |
25 |
>> Mar 1 13:53:37 fireball openvpn[27908]: Socket Buffers: |
26 |
>> R=[212992->425984] S=[212992->425984] |
27 |
>> Mar 1 13:53:37 fireball openvpn[27908]: UDP link local: (not bound) |
28 |
>> Mar 1 13:53:37 fireball openvpn[27908]: UDP link remote: |
29 |
>> [AF_INET]37.19.221.71:1194 |
30 |
>> Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS key negotiation |
31 |
>> failed to occur within 60 seconds (check your network connectivity) |
32 |
> Here's your problem ^^^ |
33 |
> |
34 |
>> Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed |
35 |
> This is your error. |
36 |
> |
37 |
> |
38 |
>> Mar 1 13:54:37 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500 |
39 |
>> 1653 10.8.8.9 255.255.255.0 restart |
40 |
>> Mar 1 13:54:37 fireball openvpn[27908]: SIGUSR1[soft,tls-error] |
41 |
>> received, process restarting |
42 |
>> Mar 1 13:54:37 fireball openvpn[27908]: Restart pause, 5 second(s) |
43 |
>> Mar 1 13:54:42 fireball openvpn[27908]: NOTE: the current |
44 |
>> --script-security setting may allow this configuration to call |
45 |
>> user-defined scripts |
46 |
>> Mar 1 13:54:42 fireball openvpn[27908]: Outgoing Control Channel |
47 |
>> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication |
48 |
>> Mar 1 13:54:42 fireball openvpn[27908]: Incoming Control Channel |
49 |
>> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication |
50 |
>> Mar 1 13:54:42 fireball openvpn[27908]: TCP/UDP: Preserving recently |
51 |
>> used remote address: [AF_INET]107.179.20.179:1194 |
52 |
>> Mar 1 13:54:42 fireball openvpn[27908]: Socket Buffers: |
53 |
>> R=[212992->425984] S=[212992->425984] |
54 |
>> Mar 1 13:54:42 fireball openvpn[27908]: UDP link local: (not bound) |
55 |
>> Mar 1 13:54:42 fireball openvpn[27908]: UDP link remote: |
56 |
>> [AF_INET]107.179.20.179:1194 |
57 |
>> Mar 1 13:55:42 fireball openvpn[27908]: TLS Error: TLS key negotiation |
58 |
>> failed to occur within 60 seconds (check your network connectivity) |
59 |
>> Mar 1 13:55:42 fireball openvpn[27908]: TLS Error: TLS handshake failed |
60 |
> Have a look here for suggestions: |
61 |
> |
62 |
> https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/ |
63 |
> |
64 |
> |
65 |
>> The weird thing, I can stop openvpn, then start it again just seconds later |
66 |
>> and it works fine for a good long while. |
67 |
> Right, the problem is with renegotiating a connection, after it times out and |
68 |
> it fails to agree TLS keys. I seem to recall a bug with this, but I think it |
69 |
> would/should have been fixed by now. |
70 |
> |
71 |
> |
72 |
>> I got this config file from Surfshark. I think it's public so I guess |
73 |
>> there's no harm posting as is. |
74 |
>> |
75 |
>> |
76 |
>> client |
77 |
>> dev tun |
78 |
>> proto udp |
79 |
>> remote us-hou.prod.surfshark.com 1194 |
80 |
>> resolv-retry infinite |
81 |
>> remote-random |
82 |
>> nobind |
83 |
>> tun-mtu 1500 |
84 |
>> tun-mtu-extra 32 |
85 |
>> mssfix 1450 |
86 |
>> persist-key |
87 |
>> persist-tun |
88 |
>> ping 15 |
89 |
>> ping-restart 0 |
90 |
>> ping-timer-rem |
91 |
>> reneg-sec 0 |
92 |
>> |
93 |
>> remote-cert-tls server |
94 |
>> |
95 |
>> auth-user-pass /etc/openvpn/login.conf |
96 |
>> mute-replay-warnings |
97 |
>> |
98 |
>> #comp-lzo |
99 |
>> verb 3 |
100 |
>> pull |
101 |
>> fast-io |
102 |
>> cipher AES-256-CBC |
103 |
>> |
104 |
>> auth SHA512 |
105 |
>> |
106 |
>> |
107 |
>> I don't see anything about DNS/nameserver/resolv.conf there but I may be |
108 |
>> missing it. When I tried to add that detail, it refused to start at all |
109 |
>> and puked on my keyboard. It was very unhappy with me telling it what DNS |
110 |
>> IP to use. That up script it runs is pretty complicated looking. I'm kinda |
111 |
>> nervous about messing with it. |
112 |
> There is no DNS problem at all. The problem is related to your client |
113 |
> renegotiating keys to encrypt the tunnel with and failing to do so. Have a |
114 |
> look at the above URL and see if any of the solutions suggested there points |
115 |
> you in the right direction. |
116 |
|
117 |
|
118 |
I read through the link. It would seem it would fail to establish any |
119 |
connection for most of those, blocked port on my end for example. Since |
120 |
it does connect and works for days, over a week even, I'd think those |
121 |
ports are open. There are others that point to the problem being on the |
122 |
other end. I have no way to check that part. So, I think my end is OK |
123 |
and their end has a hiccup somewhere. I'm using openvpn-2.5.6 and I see |
124 |
a keyworded version available. Think I should try the newer version? |
125 |
|
126 |
Given I can't find a way to manually set DNS servers, would it be fair |
127 |
to say that openvpn does it the way it does for security reasons? I've |
128 |
read that if ISPs can track DNS requests, they can learn quite a lot of |
129 |
info. It might be that openvpn requires it to be done its way for a |
130 |
security reason and pukes when one tries to override that setting. It |
131 |
sure refuses to work at all when I try to set it manually. |
132 |
|
133 |
Now to figure out what to tell Surfshark. :/ |
134 |
|
135 |
Dale |
136 |
|
137 |
:-) :-) |