Mailing List Archive

Setting a fixed nameserver for openvpn
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 

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

Thanks.

Dale

:-)  :-)

P. S.  I edited the IP address above.  I'm not sure if those are public
or not. 
Re: Setting a fixed nameserver for openvpn [ In reply to ]
On 05/03/2023 18:41, Dale wrote:
> 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
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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?


--
Neil Bothwick

There are only 10 types of people in the world:
those who understand binary and those who don't.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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'
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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 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.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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 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:


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

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

:-)  :-) 
Re: Setting a fixed nameserver for openvpn [ In reply to ]
On 06/03/2023 10:06, Michael wrote:
> 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'

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
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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 .

--
Regards,
Peter.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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
Re: Setting a fixed nameserver for openvpn [ In reply to ]
On Monday, 6 March 2023 12:05:40 GMT Wols Lists wrote:
> 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

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.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
On Mon, 6 Mar 2023 08:24:35 +0000, Wols Lists wrote:

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


--
Neil Bothwick

There are two hard things in computer science:
cache invalidation, naming things and off-by-one errors.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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,
> >>
> >> 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.


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


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


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

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.


> 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.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
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,
>>>>
>>>> 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.

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


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


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

:-)  :-) 
Re: Setting a fixed nameserver for openvpn [ In reply to ]
On Wednesday, 8 March 2023 18:30:55 GMT Dale wrote:

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

Here's your problem ^^^

> Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed

This is your error.


> 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

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/


> 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 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.
Re: Setting a fixed nameserver for openvpn [ In reply to ]
Michael wrote:
> On Wednesday, 8 March 2023 18:30:55 GMT Dale wrote:
>
>> 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)
> Here's your problem ^^^
>
>> Mar 1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed
> This is your error.
>
>
>> 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
> 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/
>
>
>> 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 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

:-)  :-) 
Re: Setting a fixed nameserver for openvpn [ In reply to ]
On Wed, 8 Mar 2023 12:30:55 -0600
Dale <rdalek1967@gmail.com> wrote:

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

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