Re: [gentoo-user] Setting a fixed nameserver for openvpn

[Dale]

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

:-)  :-)