I would recommend changing the DNS addresses on your Linux device. You
can simply do that by following the steps below.
Â
First, you need to open the terminal with the CTRL + ALT + T
combination and type in the following commands:
sudo rm -r /etc/resolv.conf
sudo nano /etc/resolv.conf
Â
You will be asked for your root password after each command line, so
just type it in and press enter. When the text editor opens, you will
have to type in these lines:
nameserver xxx.xxx.172.57
nameserver xxx.xxx.159.92
I edited the file they say with kwrite. Even after I restart openvpn,
the IP they want is there but it doesn't use it according to the site
they sent for me to check it with. It shows other IP addresses. I'm
sure I'm missing something, likely something simple, but I can't figure
out how to make it work. I don't know if it is because I'm using openrc
or what.
Anyone have a idea on how to make this work?
There's another file - can't remember its name - that tells your
resolver what to try in what order - the hosts file, dns, what dhcp
told you, etc etc, so your resolver might not be using dns the way you
think.
On Mon, 6 Mar 2023 07:54:51 +0000, Wols Lists wrote:
There's another file - can't remember its name - that tells your
resolver what to try in what order - the hosts file, dns, what dhcp
told you, etc etc, so your resolver might not be using dns the way you
think.
Do you mean /etc/nsswitch.conf?
On 06/03/2023 08:08, Neil Bothwick wrote:
On Mon, 6 Mar 2023 07:54:51 +0000, Wols Lists wrote:
There's another file - can't remember its name - that tells your
resolver what to try in what order - the hosts file, dns, what dhcp
told you, etc etc, so your resolver might not be using dns the way you
think.
Do you mean /etc/nsswitch.conf?
Ah yes. Any idea why Firefox seems to ignore it? Whenever I try to
browse to local machines in /etc/hosts, firefox gives me a google search
page which is a bloody nuisance. If I type a VALID ADDRESS in the
ADDRESS BAR, that's where I expect to go! Not some damn random search page!
Cheers,
Wol
On Monday, 6 March 2023 08:24:35 GMT Wols Lists wrote:
On 06/03/2023 08:08, Neil Bothwick wrote:
On Mon, 6 Mar 2023 07:54:51 +0000, Wols Lists wrote:
There's another file - can't remember its name - that tells your
resolver what to try in what order - the hosts file, dns, what dhcp
told you, etc etc, so your resolver might not be using dns the way you >>>> think.
Do you mean /etc/nsswitch.conf?
Ah yes. Any idea why Firefox seems to ignore it? Whenever I try to
browse to local machines in /etc/hosts, firefox gives me a google search
page which is a bloody nuisance. If I type a VALID ADDRESS in the
ADDRESS BAR, that's where I expect to go! Not some damn random search page! >>
Cheers,
Wol
I suspect the behaviour you noticed is related to FF functionality like TRR (Trusted Recursive Resolver) farming all your DNS queries over to the cloudfarce honeypot.
Have a look here if you want to disable it:
https://wiki.archlinux.org/title/Firefox/Privacy#Disable/ enforce_'Trusted_Recursive_Resolver'
On 06/03/2023 08:08, Neil Bothwick wrote:
On Mon, 6 Mar 2023 07:54:51 +0000, Wols Lists wrote:Ah yes. Any idea why Firefox seems to ignore it? Whenever I try to
There's another file - can't remember its name - that tells your
resolver what to try in what order - the hosts file, dns, what dhcp
told you, etc etc, so your resolver might not be using dns the way you
think.
Do you mean /etc/nsswitch.conf?
browse to local machines in /etc/hosts, firefox gives me a google
search page which is a bloody nuisance. If I type a VALID ADDRESS in
the ADDRESS BAR, that's where I expect to go! Not some damn random
search page!
Cheers,
Wol
On 06/03/2023 10:06, Michael wrote:
I suspect the behaviour you noticed is related to FF functionality like
TRR
(Trusted Recursive Resolver) farming all your DNS queries over to the cloudfarce honeypot.
Have a look here if you want to disable it:
https://wiki.archlinux.org/title/Firefox/Privacy#Disable/ enforce_'Trusted_Recursive_Resolver'
Thanks. That led me to network.trr.allow-rfc1918, which provided your
name has a dot in it ! appears to resolve addresses from /etc/hosts. I
guess that actually means firefox uses your local resolver first, and if
it returns an rfc1918 address, will use it.
Surely that should be the default! It shouldn't break a PRIVATE network
in the name of security !!!
Howdy,
I use Surfshark and every once in a while, my VPN loses its connection.
I sent the info from messages to Surfshark but the info they sent back
on how to set the nameserver info doesn't really work with Gentoo. I
suspect they are used to systemd stuff. Anyway, I tried to follow in a
more Gentoo way but it still didn't work. Then I googled, searched the Gentoo wiki and tried some of those things, still refuses to use the
manually entered nameserver. I've tried resolv.conf, resolvconf.conf
and resolv.conf-tun0.sv. I installed openresolv to see if that would
help. Nope.
This is what I got from Surfshark:
I would recommend changing the DNS addresses on your Linux device. You
can simply do that by following the steps below.
First, you need to open the terminal with the CTRL + ALT + T
combination and type in the following commands:
sudo rm -r /etc/resolv.conf
sudo nano /etc/resolv.conf
On Monday, 6 March 2023 10:56:37 GMT Wols Lists wrote:
On 06/03/2023 10:06, Michael wrote:
I suspect the behaviour you noticed is related to FF functionality like
TRR
(Trusted Recursive Resolver) farming all your DNS queries over to the
cloudfarce honeypot.
Have a look here if you want to disable it:
https://wiki.archlinux.org/title/Firefox/Privacy#Disable/
enforce_'Trusted_Recursive_Resolver'
Thanks. That led me to network.trr.allow-rfc1918, which provided your
name has a dot in it ! appears to resolve addresses from /etc/hosts. I
guess that actually means firefox uses your local resolver first, and if
it returns an rfc1918 address, will use it.
Surely that should be the default! It shouldn't break a PRIVATE network
in the name of security !!!
It is the default here, in www-client/firefox-110.0.1 .
On 06/03/2023 11:08, Peter Humphrey wrote:
On Monday, 6 March 2023 10:56:37 GMT Wols Lists wrote:
On 06/03/2023 10:06, Michael wrote:
I suspect the behaviour you noticed is related to FF functionality like >>> TRR
(Trusted Recursive Resolver) farming all your DNS queries over to the
cloudfarce honeypot.
Have a look here if you want to disable it:
https://wiki.archlinux.org/title/Firefox/Privacy#Disable/
enforce_'Trusted_Recursive_Resolver'
Thanks. That led me to network.trr.allow-rfc1918, which provided your
name has a dot in it ! appears to resolve addresses from /etc/hosts. I
guess that actually means firefox uses your local resolver first, and if >> it returns an rfc1918 address, will use it.
Surely that should be the default! It shouldn't break a PRIVATE network
in the name of security !!!
It is the default here, in www-client/firefox-110.0.1 .
I'm running amd not ~amd, and I've got FF 102esr. As soon as I changed
it to allow rfc1918, it started working ...
Cheers,
Wol
Do you mean /etc/nsswitch.conf?
Ah yes. Any idea why Firefox seems to ignore it? Whenever I try to
browse to local machines in /etc/hosts, firefox gives me a google
search page which is a bloody nuisance. If I type a VALID ADDRESS in
the ADDRESS BAR, that's where I expect to go! Not some damn random
search page!
On Sunday, 5 March 2023 18:41:10 GMT Dale wrote:
Howdy,AFAIR, you're meant to pull down from the openvpn server the DNS resolvers you're meant to use with their service, unless you have your own reasons for wanting to override these and set up your own DNS resolvers. Have you looked in /etc/openvpn/ for a suitable setting in the configuration file? I'm sure it will be set to automatically pull down the DNS resolvers and the Up script will set these up for your system when you start openvpn.
I use Surfshark and every once in a while, my VPN loses its connection.
I sent the info from messages to Surfshark but the info they sent back
on how to set the nameserver info doesn't really work with Gentoo. I
suspect they are used to systemd stuff. Anyway, I tried to follow in a
more Gentoo way but it still didn't work. Then I googled, searched the
Gentoo wiki and tried some of those things, still refuses to use the
manually entered nameserver. I've tried resolv.conf, resolvconf.conf
and resolv.conf-tun0.sv. I installed openresolv to see if that would
help. Nope.
This is what I got from Surfshark:Normally, you would not have to do this manually. The Up script will enter the resolver IP addresses in your resolv.conf. If it doesn't, then check your
I would recommend changing the DNS addresses on your Linux device. You
can simply do that by following the steps below.
First, you need to open the terminal with the CTRL + ALT + T
combination and type in the following commands:
sudo rm -r /etc/resolv.conf
sudo nano /etc/resolv.conf
configuration and your openvpn script.
Michael wrote:
On Sunday, 5 March 2023 18:41:10 GMT Dale wrote:
Howdy,
I use Surfshark and every once in a while, my VPN loses its connection.
I sent the info from messages to Surfshark but the info they sent back
on how to set the nameserver info doesn't really work with Gentoo. I
suspect they are used to systemd stuff. Anyway, I tried to follow in a
more Gentoo way but it still didn't work. Then I googled, searched the
Gentoo wiki and tried some of those things, still refuses to use the
manually entered nameserver. I've tried resolv.conf, resolvconf.conf
and resolv.conf-tun0.sv. I installed openresolv to see if that would
help. Nope.
AFAIR, you're meant to pull down from the openvpn server the DNS resolvers you're meant to use with their service, unless you have your own reasons for wanting to override these and set up your own DNS resolvers. Have
you looked in /etc/openvpn/ for a suitable setting in the configuration file? I'm sure it will be set to automatically pull down the DNS
resolvers and the Up script will set these up for your system when you start openvpn.
This started because I changed to doing OS updates every other weekend.
That means two weeks of login, two weeks of the VPN being active etc
etc. When doing that, the VPN would lose connection after a good
while. Sometimes it would go the whole two weeks with no problems but
on occasion it would lose connection.
I wrote a email to make them
aware to see if this is expected behavior, if I had bad settings or
something was wrong on their end. That's when I got the info in the
original post, to change DNS servers. I'm not sure what that has to do
with anything but . . .
You know how awful I am with scripts. Still, I read through the up
script and even to me, it looks like it is set up to get DNS servers
during the connection setup. This is the part I see.
elif [ "${opt}" != "${opt#dhcp-option DNS *}" ] ; then
NS="${NS}nameserver ${opt#dhcp-option DNS *}\n"
To me, it seems like it is getting the DNS info and putting it
somewhere. It appears that wherever it puts it, it is the only place it looks because nothing I change changes where it goes for DNS info. To
be honest, I don't know why it should have to be changed. One would
think that the DNS info they send should work fine otherwise why set it
up that way.
This is what I got from Surfshark:
I would recommend changing the DNS addresses on your Linux device. You >>> can simply do that by following the steps below.
First, you need to open the terminal with the CTRL + ALT + T
combination and type in the following commands:
sudo rm -r /etc/resolv.conf
sudo nano /etc/resolv.conf
Normally, you would not have to do this manually. The Up script will
enter
the resolver IP addresses in your resolv.conf. If it doesn't, then check your configuration and your openvpn script.
I tried to edit the openvpn.conf file to manually set the nameserver but
it puked on my keyboard and refused to even connect. I think we are
back to the server I connect to requires its info to be used and if it
isn't, it refuses to complete the connection. Everything I try results
in a error and connection refused. It could even be a security setting
that requires this.
Either way, either this can't be changed and the VPN connect or there is
a setting somewhere that we are not aware of. I've googled, asked here
plus looked everywhere I can think of, even some places I couldn't
imagine having anything to do with it, and had no luck finding where it stores the info or how to change it.
Unless someone comes up with a idea, I'm fresh out. I have no clue what
to do. Hey, it does work almost all the time. It's not the end of the world.
Thanks.
Dale
:-) :-)
P. S. Getting close to garden time. :-D
On Tuesday, 7 March 2023 18:11:01 GMT Dale wrote:
Michael wrote:When a connection goes down the openvpn client log would provide the reason for it. It makes sense to start from there any troubleshooting effort. The DNS resolvers used within the tunnel may be a symptom, rather than the cause.
On Sunday, 5 March 2023 18:41:10 GMT Dale wrote:This started because I changed to doing OS updates every other weekend.
Howdy,AFAIR, you're meant to pull down from the openvpn server the DNS resolvers >>> you're meant to use with their service, unless you have your own reasons >>> for wanting to override these and set up your own DNS resolvers. Have
I use Surfshark and every once in a while, my VPN loses its connection. >>>> I sent the info from messages to Surfshark but the info they sent back >>>> on how to set the nameserver info doesn't really work with Gentoo. I
suspect they are used to systemd stuff. Anyway, I tried to follow in a >>>> more Gentoo way but it still didn't work. Then I googled, searched the >>>> Gentoo wiki and tried some of those things, still refuses to use the
manually entered nameserver. I've tried resolv.conf, resolvconf.conf
and resolv.conf-tun0.sv. I installed openresolv to see if that would
help. Nope.
you looked in /etc/openvpn/ for a suitable setting in the configuration
file? I'm sure it will be set to automatically pull down the DNS
resolvers and the Up script will set these up for your system when you
start openvpn.
That means two weeks of login, two weeks of the VPN being active etc
etc. When doing that, the VPN would lose connection after a good
while. Sometimes it would go the whole two weeks with no problems but
on occasion it would lose connection.
I wrote a email to make themHeh! Same here, unless the server side logs indicated this was where the problem actually occurred with your connection.
aware to see if this is expected behavior, if I had bad settings or
something was wrong on their end. That's when I got the info in the
original post, to change DNS servers. I'm not sure what that has to do
with anything but . . .
You know how awful I am with scripts. Still, I read through the upDNS resolvers will be added to your resolv.conf when the tunnel comes up.
script and even to me, it looks like it is set up to get DNS servers
during the connection setup. This is the part I see.
elif [ "${opt}" != "${opt#dhcp-option DNS *}" ] ; then
NS="${NS}nameserver ${opt#dhcp-option DNS *}\n"
To me, it seems like it is getting the DNS info and putting it
somewhere. It appears that wherever it puts it, it is the only place it
looks because nothing I change changes where it goes for DNS info. To
be honest, I don't know why it should have to be changed. One would
think that the DNS info they send should work fine otherwise why set it
up that way.
Instead of messing up with the scripts and hardcoding nameserver IP addresses,
have you done any troubleshooting to find out what part of the connection goes
down? Is the tunnel still up? Can you ping IP addresses through the tunnel?
etc.
I recall the openvpn.conf has an entry to specify pulling down the DNS resolvers from the server as it is establishing the tunnel. Here's some troubleshooting to confirm if this is the problem, after you reset to defaultsI tried to edit the openvpn.conf file to manually set the nameserver butThis is what I got from Surfshark:Normally, you would not have to do this manually. The Up script will
I would recommend changing the DNS addresses on your Linux device. You >>>>> can simply do that by following the steps below.
First, you need to open the terminal with the CTRL + ALT + T
combination and type in the following commands:
sudo rm -r /etc/resolv.conf
sudo nano /etc/resolv.conf
enter
the resolver IP addresses in your resolv.conf. If it doesn't, then check >>> your configuration and your openvpn script.
it puked on my keyboard and refused to even connect. I think we are
back to the server I connect to requires its info to be used and if it
isn't, it refuses to complete the connection. Everything I try results
in a error and connection refused. It could even be a security setting
that requires this.
everything you interfered with in the openvpn.conf settings.
Either way, either this can't be changed and the VPN connect or there isI suggest you test for one thing at a time when the connection fails and start
a setting somewhere that we are not aware of. I've googled, asked here
plus looked everywhere I can think of, even some places I couldn't
imagine having anything to do with it, and had no luck finding where it
stores the info or how to change it.
Unless someone comes up with a idea, I'm fresh out. I have no clue what
to do. Hey, it does work almost all the time. It's not the end of the
world.
Thanks.
Dale
:-) :-)
P. S. Getting close to garden time. :-D
with the logs. Hardcoding the DNS resolver addresses may not be the problem you're facing here.
It starts at about 13:54. It seems to try to reconnect but can't. I got this by using tail -n and then grep openvpn on the end.
Mar 1 13:53:32 fireball openvpn[27908]:
[us-hou-v029.prod.surfshark.com] Inactivity timeout (--ping-restart), restarting
Mar 1 13:53:32 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
1584 10.8.8.9 255.255.255.0 restart
Mar 1 13:53:32 fireball openvpn[27908]: SIGUSR1[soft,ping-restart]
received, process restarting
Mar 1 13:53:32 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar 1 13:53:37 fireball openvpn[27908]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Mar 1 13:53:37 fireball openvpn[27908]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Mar 1 13:53:37 fireball openvpn[27908]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Mar 1 13:53:37 fireball openvpn[27908]: TCP/UDP: Preserving recently
used remote address: [AF_INET]37.19.221.71:1194
Mar 1 13:53:37 fireball openvpn[27908]: Socket Buffers:
R=[212992->425984] S=[212992->425984]
Mar 1 13:53:37 fireball openvpn[27908]: UDP link local: (not bound)
Mar 1 13:53:37 fireball openvpn[27908]: UDP link remote: [AF_INET]37.19.221.71:1194
Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed
Mar 1 13:54:37 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
1653 10.8.8.9 255.255.255.0 restart
Mar 1 13:54:37 fireball openvpn[27908]: SIGUSR1[soft,tls-error]
received, process restarting
Mar 1 13:54:37 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar 1 13:54:42 fireball openvpn[27908]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Mar 1 13:54:42 fireball openvpn[27908]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Mar 1 13:54:42 fireball openvpn[27908]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Mar 1 13:54:42 fireball openvpn[27908]: TCP/UDP: Preserving recently
used remote address: [AF_INET]107.179.20.179:1194
Mar 1 13:54:42 fireball openvpn[27908]: Socket Buffers:
R=[212992->425984] S=[212992->425984]
Mar 1 13:54:42 fireball openvpn[27908]: UDP link local: (not bound)
Mar 1 13:54:42 fireball openvpn[27908]: UDP link remote: [AF_INET]107.179.20.179:1194
Mar 1 13:55:42 fireball openvpn[27908]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 1 13:55:42 fireball openvpn[27908]: TLS Error: TLS handshake failed
The weird thing, I can stop openvpn, then start it again just seconds later and it works fine for a good long while.
I got this config file from Surfshark. I think it's public so I guess there's no harm posting as is.
client
dev tun
proto udp
remote us-hou.prod.surfshark.com 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
remote-cert-tls server
auth-user-pass /etc/openvpn/login.conf
mute-replay-warnings
#comp-lzo
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512
I don't see anything about DNS/nameserver/resolv.conf there but I may be missing it. When I tried to add that detail, it refused to start at all
and puked on my keyboard. It was very unhappy with me telling it what DNS
IP to use. That up script it runs is pretty complicated looking. I'm kinda nervous about messing with it.
Michael wrote:
On Tuesday, 7 March 2023 18:11:01 GMT Dale wrote:
Michael wrote:
On Sunday, 5 March 2023 18:41:10 GMT Dale wrote:
Howdy,
This is from the messages file. I don't see it logged anywhere else.
It starts at about 13:54. It seems to try to reconnect but can't. I got this by using tail -n and then grep openvpn on the end.
Mar 1 13:53:32 fireball openvpn[27908]:<anip>
[us-hou-v029.prod.surfshark.com] Inactivity timeout (--ping-restart), restarting
Mar 1 13:53:32 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
1584 10.8.8.9 255.255.255.0 restart
Mar 1 13:53:32 fireball openvpn[27908]: SIGUSR1[soft,ping-restart]
received, process restarting
Mar 1 13:53:32 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar 1 13:53:37 fireball openvpn[27908]: NOTE: the current
The weird thing, I can stop openvpn, then start it again just seconds later and it works fine for a good long while.
On Wednesday, 8 March 2023 18:30:55 GMT Dale wrote:0
It starts at about 13:54. It seems to try to reconnect but can't. I got this >> by using tail -n and then grep openvpn on the end.
Mar 1 13:53:32 fireball openvpn[27908]:
[us-hou-v029.prod.surfshark.com] Inactivity timeout (--ping-restart),
restarting
Mar 1 13:53:32 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 150
1584 10.8.8.9 255.255.255.0 restartHere's your problem ^^^
Mar 1 13:53:32 fireball openvpn[27908]: SIGUSR1[soft,ping-restart]
received, process restarting
Mar 1 13:53:32 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar 1 13:53:37 fireball openvpn[27908]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Mar 1 13:53:37 fireball openvpn[27908]: Outgoing Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication >> Mar 1 13:53:37 fireball openvpn[27908]: Incoming Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication >> Mar 1 13:53:37 fireball openvpn[27908]: TCP/UDP: Preserving recently
used remote address: [AF_INET]37.19.221.71:1194
Mar 1 13:53:37 fireball openvpn[27908]: Socket Buffers:
R=[212992->425984] S=[212992->425984]
Mar 1 13:53:37 fireball openvpn[27908]: UDP link local: (not bound)
Mar 1 13:53:37 fireball openvpn[27908]: UDP link remote:
[AF_INET]37.19.221.71:1194
Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS key negotiation
failed to occur within 60 seconds (check your network connectivity)
Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failedThis is your error.
0Mar 1 13:54:37 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 150
1653 10.8.8.9 255.255.255.0 restartHave a look here for suggestions:
Mar 1 13:54:37 fireball openvpn[27908]: SIGUSR1[soft,tls-error]
received, process restarting
Mar 1 13:54:37 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar 1 13:54:42 fireball openvpn[27908]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Mar 1 13:54:42 fireball openvpn[27908]: Outgoing Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication >> Mar 1 13:54:42 fireball openvpn[27908]: Incoming Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication >> Mar 1 13:54:42 fireball openvpn[27908]: TCP/UDP: Preserving recently
used remote address: [AF_INET]107.179.20.179:1194
Mar 1 13:54:42 fireball openvpn[27908]: Socket Buffers:
R=[212992->425984] S=[212992->425984]
Mar 1 13:54:42 fireball openvpn[27908]: UDP link local: (not bound)
Mar 1 13:54:42 fireball openvpn[27908]: UDP link remote:
[AF_INET]107.179.20.179:1194
Mar 1 13:55:42 fireball openvpn[27908]: TLS Error: TLS key negotiation
failed to occur within 60 seconds (check your network connectivity)
Mar 1 13:55:42 fireball openvpn[27908]: TLS Error: TLS handshake failed
https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/
The weird thing, I can stop openvpn, then start it again just seconds later >> and it works fine for a good long while.Right, the problem is with renegotiating a connection, after it times out and
it fails to agree TLS keys. I seem to recall a bug with this, but I think it
would/should have been fixed by now.
I got this config file from Surfshark. I think it's public so I guessThere is no DNS problem at all. The problem is related to your client renegotiating keys to encrypt the tunnel with and failing to do so. Have a look at the above URL and see if any of the solutions suggested there points you in the right direction.
there's no harm posting as is.
client
dev tun
proto udp
remote us-hou.prod.surfshark.com 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
remote-cert-tls server
auth-user-pass /etc/openvpn/login.conf
mute-replay-warnings
#comp-lzo
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512
I don't see anything about DNS/nameserver/resolv.conf there but I may be
missing it. When I tried to add that detail, it refused to start at all
and puked on my keyboard. It was very unhappy with me telling it what DNS >> IP to use. That up script it runs is pretty complicated looking. I'm kinda >> nervous about messing with it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 303 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 89:39:21 |
| Calls: | 6,812 |
| Calls today: | 4 |
| Files: | 12,328 |
| Messages: | 5,401,953 |