OpenVPN internet connection problem

I used the default configuration file for Linux systems from ProtonVPN (for OpenVPN).
I start OpenVPN once via the 'onestart' command, it then asks for the username and password.
After this it connects, and it seems to connect correctly, but I have no internet and can't ping the google servers either.

This is my configuration:
Code:
# ==============================================================================
# Copyright (c) 2016-2020 Proton Technologies AG (Switzerland)
# Email: contact@protonvpn.com
#
# The MIT License (MIT)
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR # OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
# ==============================================================================
# If you want to enable the ProtonVPN ad blocker (NetShield):
# Use: "VGYNcS1AZoSH4ptOYJ51s_8v+f1" as username to enable anti-malware filtering
# Use: "VGYNcS1AZoSH4ptOYJ51s_8v+f2" as username to additionally enable ad-blocking filtering.

client
dev tun
proto udp

remote 89.38.99.188 1194
remote 89.38.99.188 5060
remote 89.38.99.188 80
remote 89.38.99.188 443
remote 89.38.99.188 4569

remote-random
resolv-retry infinite
nobind

# The following setting is only needed for old OpenVPN clients compatibility. New clients
# automatically negotiate the optimal cipher.
cipher AES-256-CBC

auth SHA512
verb 3
setenv CLIENT_CERT 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
reneg-sec 0
remote-cert-tls server
auth-user-pass
pull
fast-io
script-security 2

#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf

CERTIFICATE
xx
xx
xx
xx


OpenVPN Static key V1
xx
xx
xx
xx

This is the log:
Code:
Dec  6 17:53:50 fatetrap openvpn[64768]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Dec  6 17:53:50 fatetrap openvpn[64768]: OpenVPN 2.5.4 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov  5 2021
Dec  6 17:53:50 fatetrap openvpn[64768]: library versions: OpenSSL 1.1.1h-freebsd  22 Sep 2020, LZO 2.10
Dec  6 17:55:08 fatetrap openvpn[67939]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  6 17:55:08 fatetrap openvpn[67939]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  6 17:55:08 fatetrap openvpn[67939]: TCP/UDP: Preserving recently used remote address: [AF_INET]xxxxxxxxx
Dec  6 17:55:08 fatetrap openvpn[67939]: Socket Buffers: R=[42080->42080] S=[9216->9216]
Dec  6 17:55:08 fatetrap openvpn[67939]: UDP link local: (not bound)
Dec  6 17:55:08 fatetrap openvpn[67939]: UDP link remote: [AF_INET]xxxxxxxxx
Dec  6 17:55:08 fatetrap openvpn[67939]: TLS: Initial packet from [AF_INET]xxxxxxxxx, sid=xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: VERIFY OK: depth=1, C=CH, O=ProtonVPN AG, CN=ProtonVPN Intermediate CA 1
Dec  6 17:55:09 fatetrap openvpn[67939]: VERIFY KU OK
Dec  6 17:55:09 fatetrap openvpn[67939]: Validating certificate extended key usage
Dec  6 17:55:09 fatetrap openvpn[67939]: ++ Certificate has EKU (str) xxxxxxxxx, expects TLS Web Server Authentication
Dec  6 17:55:09 fatetrap openvpn[67939]: ++ Certificate has EKU (oid) xxxxxxxxx, expects TLS Web Server Authentication
Dec  6 17:55:09 fatetrap openvpn[67939]: ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Server Authentication
Dec  6 17:55:09 fatetrap openvpn[67939]: ++ Certificate has EKU (oid) xxxxxxxxx, expects TLS Web Server Authentication
Dec  6 17:55:09 fatetrap openvpn[67939]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Dec  6 17:55:09 fatetrap openvpn[67939]: VERIFY EKU OK
Dec  6 17:55:09 fatetrap openvpn[67939]: VERIFY OK: depth=0, CN=xxxx.protonvpn.com
Dec  6 17:55:09 fatetrap openvpn[67939]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634'
Dec  6 17:55:09 fatetrap openvpn[67939]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Dec  6 17:55:09 fatetrap openvpn[67939]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
Dec  6 17:55:09 fatetrap openvpn[67939]: [xxx.protonvpn.com] Peer Connection Initiated with [AF_INET]xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS xxxxxx,sndbuf 524288,rcvbuf 524288,redirect-gateway def1,explicit-exit-notify,comp-lzo no,route-gateway xxxx,topology subnet,ping 10,ping-restart 60,socket-flags TCP_NODELAY,ifconfig xxxxxxxxx,peer-id 196618,cipher AES-256-GCM'
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: timers and/or timeouts modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: explicit notify parm(s) modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: compression parms modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Dec  6 17:55:09 fatetrap openvpn[67939]: Socket Buffers: R=[42080->524288] S=[9216->524288]
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: --socket-flags option modified
Dec  6 17:55:09 fatetrap openvpn[67939]: NOTE: setsockopt TCP_NODELAY=1 failed
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: --ifconfig/up options modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: route options modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: route-related options modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: peer-id set
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: adjusting link_mtu to 1656
Dec  6 17:55:09 fatetrap openvpn[67939]: OPTIONS IMPORT: data channel crypto options modified
Dec  6 17:55:09 fatetrap openvpn[67939]: Data Channel: using negotiated cipher 'AES-256-GCM'
Dec  6 17:55:09 fatetrap openvpn[67939]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec  6 17:55:09 fatetrap openvpn[67939]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec  6 17:55:09 fatetrap openvpn[67939]: ROUTE_GATEWAY xxxxxxxxx IFACE=re0 HWADDR=xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: TUN/TAP device /dev/tun0 opened
Dec  6 17:55:09 fatetrap kernel: tun0: link state changed to UP
Dec  6 17:55:09 fatetrap openvpn[67939]: /sbin/ifconfig tun0xxxxxxxxx mtu 1500 netmask 255.255.0.0 up
Dec  6 17:55:09 fatetrap openvpn[67939]: /sbin/route add -net xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: /sbin/route add -net xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: /sbin/route add -net xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: /sbin/route add -net xxxxxxxxx
Dec  6 17:55:09 fatetrap openvpn[67939]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Dec  6 17:55:09 fatetrap openvpn[67939]: Initialization Sequence Completed
Dec  6 18:00:35 fatetrap su[5945]: user to root on /dev/pts/0
Dec  6 18:00:38 fatetrap openvpn[67939]: event_wait : Interrupted system call (code=4)
Dec  6 18:00:38 fatetrap openvpn[67939]: SIGTERM received, sending exit notification to peer
Dec  6 18:00:39 fatetrap openvpn[67939]: /sbin/route delete -net xxxxxxxxx
Dec  6 18:00:39 fatetrap openvpn[67939]: /sbin/route delete -net xxxxxxxxx
Dec  6 18:00:39 fatetrap openvpn[67939]: /sbin/route delete -net xxxxxxxxx
Dec  6 18:00:39 fatetrap openvpn[67939]: Closing TUN/TAP interface
Dec  6 18:00:39 fatetrap openvpn[67939]: /sbin/ifconfig tun0 destroy
Dec  6 18:00:39 fatetrap kernel: tun0: link state changed to DOWN
Dec  6 18:00:39 fatetrap openvpn[67939]: SIGTERM[soft,exit-with-notification] received, process exiting
I've replaced certain things with xxxx where it might compromise my privacy.

Is there anyone who sees an explanation in the config file or in the log as to why it is not establishing an internet connection even though OpenVPN is running?
 
Try the official OpenVPN installation guide
I had used that installation guide. I get this message while following this instruction:
Code:
chmod: /etc/openvpn/update-resolv-conf: No such file or directory
You can see I fixed this problem in the config file:
Code:
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf
How should I proceed?
 
Keep in mind that on FreeBSD OpenVPN's configuration is in /usr/local/etc/openvpn, not /etc/openvpn as is common on Linux.

If you use PF then you will need to reload the rules when the tunnel is activated. You also need to make sure the traffic is actually allowed through the tunnel.
 
If you use PF then you will need to reload the rules when the tunnel is activated. You also need to make sure the traffic is actually allowed through the tunnel.
I don't use PF.
Keep in mind that on FreeBSD OpenVPN's configuration is in /usr/local/etc/openvpn, not /etc/openvpn as is common on Linux.
My configuration files are located in /usr/local/etc/openvpn and I know this is the configuration directory for FreeBSD. There is indeed the /etc/openvpn entry in the configuration file, but update-resolv-conf in FreeBSD is neither in /usr/local/etc/openvpn nor in /etc/openvpn.

Here is some additional information on the subject:

Also note that the official instructions for FreeBSD mention chmod +x /etc/openvpn/update-resolv-conf. Well, these are just erroneous instructions. OpenVPN is the most popular VPN client. It is important that the current information is corrected. In some countries fourty percent of the inhabitants use a VPN. A networking expert should contact ovpn.com and have the FreeBSD instructions updated.

I thought I could solve this problem with the resolvconf by configuring these lines:
Code:
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf

I'm not sure about this now. I'm wondering if a working resolv-conf configuration is necessary for OpenVPN to work or not.
I would greatly appreciate any help.
 
I'm wondering if a working resolv-conf configuration is necessary for OpenVPN to work or not.
Probably not. The question is, can you ping by IP address or not? If you can't get plain IP traffic in/out the tunnel then the whole question of DNS resolving is kind of moot.
 
Probably not. The question is, can you ping by IP address or not? If you can't get plain IP traffic in/out the tunnel then the whole question of DNS resolving is kind of moot.
I don't know much about the subject, but so I tried to ping the google servers, and then I tried to ping the configured ip address and this was the result:
Code:
$ ping -c 10 google.com
ping: cannot resolve google.com: Host name lookup failure
$ ping -c 10 89.38.99.188
PING 89.38.99.188 (89.38.99.188): 56 data bytes
64 bytes from 89.38.99.188: icmp_seq=0 ttl=55 time=20.919 ms
64 bytes from 89.38.99.188: icmp_seq=1 ttl=55 time=20.370 ms
64 bytes from 89.38.99.188: icmp_seq=2 ttl=55 time=21.455 ms
64 bytes from 89.38.99.188: icmp_seq=3 ttl=55 time=20.824 ms
64 bytes from 89.38.99.188: icmp_seq=4 ttl=55 time=20.761 ms
64 bytes from 89.38.99.188: icmp_seq=5 ttl=55 time=20.761 ms
64 bytes from 89.38.99.188: icmp_seq=6 ttl=55 time=20.064 ms
64 bytes from 89.38.99.188: icmp_seq=7 ttl=55 time=21.086 ms
64 bytes from 89.38.99.188: icmp_seq=8 ttl=55 time=27.235 ms
64 bytes from 89.38.99.188: icmp_seq=9 ttl=55 time=22.640 ms

--- 89.38.99.188 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.064/21.612/27.235/1.987 ms
$

It seems to me that I am connected to the ProtonVPN servers, but I can't make contact with other servers.
What could be the cause?
 
Did you do those tests with the tunnel active? Can you post the output from netstat -4rn when the tunnel is active?
 
Did you do those tests with the tunnel active? Can you post the output from netstat -4rn when the tunnel is active?
I did the above tests after running the service openvpn onestart command.

Here is the output of the netstat command when openvpn is running:
Code:
$ netstat -4rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
0.0.0.0/1          10.20.0.1          UGS        tun0
default            192.168.0.1        UGS         re0
10.20.0.0/16       10.20.0.1          UGS        tun0
10.20.0.1          link#3             UH         tun0
10.20.0.18         link#3             UHS         lo0
89.38.99.188/32    192.168.0.1        UGS         re0
127.0.0.1          link#2             UH          lo0
128.0.0.0/1        10.20.0.1          UGS        tun0
192.168.0.0/24     link#1             U           re0
192.168.0.19       link#1             UHS         lo0
$
 
The server is pushing route-gateway to you there you should get route, DNS, IP etc.

But you have:
event_wait : Interrupted system call (code=4)
...
Closing TUN/TAP interface
...
/sbin/ifconfig tun0 destroy
...
tun0: link state changed to DOWN

.. in your log file. Is’t you that’s stopping OpenVPN connection or is it the client?
It’s reconfiguring which terminates and restarts the client process. So non fully connection (see MTU below).

This problem is probably you config file that not mach the server side.


[Not recommended]
You may force a route from you client with something like: (you need to change the IP, I took it from your $ netstat -4rn)
Code:
route-nopull
route 10.20.0.0 255.255.255.0
route-metric 50
..but.. the best way is to get it from the server.
[Not recommended END]


You don’t need/should change you local resolv-conf as you get this from the server on route-gateway.


I see that you have
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634’
.. in you log file and you have:
Code:
tun-mtu 1500
mssfix 1450
.. in your config witch can be a performance problem. Try to lower your side as the server side is on 1500.
This may solve some problem in you connections as you set MTU before the route. You may test diffrent MTUs as well.

The server may also adjust the MTU if you see an error (something like this) in you log files:
WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500
Try to commit out tun-mtu/mssfix and restart the openvpn client. You may not need them!

You can try what MTU limit you have on you connection.
# ping -f -l 1500 SERVER_OPENVPN_IP 10.20.0.1?
Lower the MTU to 1490, 1480, 1470.. to you don’t have any packet loss, then there is you limit on -> this <- connection.


You also have:
WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
And you don’t have comp-lzo no in your file, but the server is pushing comp-lzo.

Insert:
Code:
comp-lzo no
.. in you file. Server side is pushing comp-lzo no to you.

Try this new MTU etc. and see what error you get (print them here so we see them)
 
Back
Top