[gentoo-user] Setting a fixed nameserver for openvpn

[Dale]

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.

I might add, a lot of this stuff is written for people using systemd and
I use openrc here.  I found one that had I think the right info but
neglected to name the file that needed to be edited, sounds like
something I'd do really.  lol 

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
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
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? 

Thanks.

Dale

:-)  :-)

P. S.  I edited the IP address above.  I'm not sure if those are public
or not. 

[Wols Lists]

Post by Dale
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?

resolv.conf tells DNS where to look. That's not openrc/systemd specific.

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.

I can't get that to work, either. I want my hosts file to take priority,
but it's ignored.

And then, of course, to really screw you over your ISP might be
hijacking dns.

Cheers,
Wol

[Neil Bothwick]

Post by Wols Lists
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?

[Wols Lists]

Post by Neil Bothwick

Post by Wols Lists
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

[Michael]

Post by Wols Lists

Post by Neil Bothwick

Post by Wols Lists
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'

[Wols Lists]

Post by Michael

Post by Wols Lists

Post by Neil Bothwick

Post by Wols Lists
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.
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 !!!

Cheers,
Wol

[Peter Humphrey]

Post by Wols Lists

Post by Michael
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.
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 .

[Wols Lists]

Post by Peter Humphrey

Post by Wols Lists

Post by Michael
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.
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

[Michael]

Post by Wols Lists

Post by Peter Humphrey

Post by Wols Lists

Post by Michael
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.
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

As I understand it the purpose of this setting is to avoid web attacks being
able to redirect to local private addresses, which may be hosting vulnerable
services - a.k.a. 'DNS-rebinding'. The default setting is 'false' in FF
102.8.0, but if you have disabled TRR it appears the effects of
network.trr.allow-rfc1918 are disabled too.

[Dale]

Post by Wols Lists

Post by Neil Bothwick

Post by Wols Lists
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 found where someone posted about Firefox, it seems you can change that
in preferences.  You just uncheck a box.  Anyway.

I looked at the nsswitch file.  I'm not 100% sure what it says but it
looks like others I've found.  Basically, it points to /etc and that's
it, for network stuff anyway.  So, I dug around some more.  I found a
command that shows what it is seeing and should be using.  This is the info:


***@fireball / # resolvconf -l
# resolv.conf from tun0
# Generated by openvpn for interface tun0
nameserver 162.252.172.57
nameserver 149.154.159.92

# resolv.conf from tun0.inet
nameserver 162.252.172.57
nameserver 149.154.159.92

# resolv.conf from enp3s0
# Generated by netifrc for interface enp3s0
nameserver 8.8.8.8
nameserver 8.8.4.4

# resolv.conf from enp3s0.dhcp
# Generated by dhcpcd from enp3s0.dhcp
nameserver 10.0.0.1

***@fireball / #


I left the IPs Surfshark gave me in this one.  As you can see tho, for
my VPN it should be using the ones I'm telling it to use, manually. 
Thing is, it isn't.  This is a link to the website Surfshark sent me and
the info it says it is using for DNS lookup. 

https://surfshark.com/check

DNS addresses:
107.179.20.190 / United States of America, Los Angeles / LayerHost

As one can tell, I don't have the IP for DNS listed anywhere up there. 
So, it seems one part is seeing the changes I want to make but the rest
is just plain ignoring me.  Do I need to do something for those to take
effect or do they just work?  I restarted both the VPN and my regular
network.  What am I missing here? 

Thanks.

Dale

:-)  :-) 

[Neil Bothwick]

Post by Wols Lists

Post by Neil Bothwick
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!

I see the same with Chromium sometimes, as the same input field is used
for addresses and search terms and the browser has to make a guess at
which you mean. With Chromium the solution is to add a trailing slash.

[Michael]

Post by Dale
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.

Post by Dale

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
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.

[Dale]

Post by Michael

Post by Dale
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. 

Post by Michael

Post by Dale

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
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

[Michael]

Post by Dale

Post by Michael

Post by Dale
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.

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.

Post by Dale
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 . . .

Heh! Same here, unless the server side logs indicated this was where the
problem actually occurred with your connection.

Post by Dale
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.

DNS resolvers will be added to your resolv.conf when the tunnel comes up.

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.

Post by Dale

Post by Michael

Post by Dale

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
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.

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 defaults
everything you interfered with in the openvpn.conf settings.

Post by Dale
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

I suggest you test for one thing at a time when the connection fails and start
with the logs. Hardcoding the DNS resolver addresses may not be the problem
you're facing here.

[Dale]

Post by Michael

Post by Dale

Post by Michael

Post by Dale
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.

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.

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]:
[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
Mar  1 13:55:42 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
1653 10.8.8.9 255.255.255.0 restart
Mar  1 13:55:42 fireball openvpn[27908]: SIGUSR1[soft,tls-error]
received, process restarting
Mar  1 13:55:42 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar  1 13:55:47 fireball openvpn[27908]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Mar  1 13:55:47 fireball openvpn[27908]: Outgoing Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mar  1 13:55:47 fireball openvpn[27908]: Incoming Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mar  1 13:55:47 fireball openvpn[27908]: TCP/UDP: Preserving recently
used remote address: [AF_INET]107.179.20.197:1194
Mar  1 13:55:47 fireball openvpn[27908]: Socket Buffers:
R=[212992->425984] S=[212992->425984]
Mar  1 13:55:47 fireball openvpn[27908]: UDP link local: (not bound)
Mar  1 13:55:47 fireball openvpn[27908]: UDP link remote:
[AF_INET]107.179.20.197:1194
Mar  1 13:56:47 fireball openvpn[27908]: TLS Error: TLS key negotiation
failed to occur within 60 seconds (check your network connectivity)
Mar  1 13:56:47 fireball openvpn[27908]: TLS Error: TLS handshake failed
Mar  1 13:56:47 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
1653 10.8.8.9 255.255.255.0 restart
Mar  1 13:56:47 fireball openvpn[27908]: SIGUSR1[soft,tls-error]
received, process restarting
Mar  1 13:56:47 fireball openvpn[27908]: Restart pause, 5 second(s)
Mar  1 13:56:52 fireball openvpn[27908]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Mar  1 13:56:52 fireball openvpn[27908]: Outgoing Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mar  1 13:56:52 fireball openvpn[27908]: Incoming Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mar  1 13:56:52 fireball openvpn[27908]: TCP/UDP: Preserving recently
used remote address: [AF_INET]107.179.20.203:1194
Mar  1 13:56:52 fireball openvpn[27908]: Socket Buffers:
R=[212992->425984] S=[212992->425984]
Mar  1 13:56:52 fireball openvpn[27908]: UDP link local: (not bound)
Mar  1 13:56:52 fireball openvpn[27908]: UDP link remote:
[AF_INET]107.179.20.203:1194


The weird thing, I can stop openvpn, then start it again just seconds later and it works fine for a good long while.

Post by Michael

Post by Dale
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 . . .

Heh! Same here, unless the server side logs indicated this was where the
problem actually occurred with your connection.

Post by Dale
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.

DNS resolvers will be added to your resolv.conf when the tunnel comes up.
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.

When it stops working, nothing goes through.  My cell phone, which
connects directly to the router and doesn't use the VPN, does work so I
know my internet is working.  Everything else just shows it is trying to
connect, which is usually very fast.  I'm loving this fiber internet. 

Post by Michael

Post by Dale

Post by Michael

Post by Dale

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
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.

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 defaults
everything you interfered with in the openvpn.conf settings.

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.

Post by Michael

Post by Dale
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

I suggest you test for one thing at a time when the connection fails and start
with the logs. Hardcoding the DNS resolver addresses may not be the problem
you're facing here.

I posted basically the same info I sent to Surfshark above.  Maybe you
will see something they didn't.  If you need me to check or post
something else, just let me know.  As for testing when it dies on me,
that could involve some wait time.  ;-)

Thanks.

Dale

:-)  :-) 

[Michael]

Post by Dale
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.
[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
R=[212992->425984] S=[212992->425984]
Mar 1 13:53:37 fireball openvpn[27908]: UDP link local: (not bound)
[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)

Here's your problem ^^^

Post by Dale
Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed

This is your error.

Post by Dale
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
R=[212992->425984] S=[212992->425984]
Mar 1 13:54:42 fireball openvpn[27908]: UDP link local: (not bound)
[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

Have a look here for suggestions:

https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/

Post by Dale
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.

Post by Dale
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.

There 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.

[Dale]

Post by Michael

Post by Dale
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.
[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

0

Post by Michael

Post by Dale
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
R=[212992->425984] S=[212992->425984]
Mar 1 13:53:37 fireball openvpn[27908]: UDP link local: (not bound)
[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)

Here's your problem ^^^

Post by Dale
Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed

This is your error.

Post by Dale
Mar 1 13:54:37 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 150

0

Post by Michael

Post by Dale
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
R=[212992->425984] S=[212992->425984]
Mar 1 13:54:42 fireball openvpn[27908]: UDP link local: (not bound)
[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/

Post by Dale
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.

Post by Dale
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.

There 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.

I read through the link.  It would seem it would fail to establish any
connection for most of those, blocked port on my end for example.  Since
it does connect and works for days, over a week even, I'd think those
ports are open.  There are others that point to the problem being on the
other end.  I have no way to check that part.  So, I think my end is OK
and their end has a hiccup somewhere.  I'm using openvpn-2.5.6 and I see
a keyworded version available.  Think I should try the newer version? 

Given I can't find a way to manually set DNS servers, would it be fair
to say that openvpn does it the way it does for security reasons?  I've
read that if ISPs can track DNS requests, they can learn quite a lot of
info.  It might be that openvpn requires it to be done its way for a
security reason and pukes when one tries to override that setting.  It
sure refuses to work at all when I try to set it manually. 

Now to figure out what to tell Surfshark.  :/

Dale

:-)  :-) 

[Security]

On Wed, 8 Mar 2023 12:30:55 -0600

Post by Dale

Post by Dale
Howdy,

<snip>

Post by Dale
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.
[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

<anip>

Post by Dale
The weird thing, I can stop openvpn, then start it again just seconds later and it works fine for a good long while.

<snip>
I have seen OpenVPN get stuck and not process a SIGUSR1 properly. Maybe try setting remap-usr1 to SIGHUP in the configuration to reset the state of openvpn or run external kicker script.