I’m trying to use VPN (OpenVPN via the Gnome NetworkManager) (provider is VyprVPN in my case) and as told in the title, I can establish a connection, but the connection does not “grip” so to speak.
I’m using this guide:
It’s outdated and for Ubuntu, but the steps are the same…
When I switch the toggle to establish a connection, it does connect, but:
It has no effect.
Let’s say I want to connect to a Japanese server (gateway jp1.vpn.goldenfrog.com). I switch the toggle, it connects. But when I check the connection, for example directly on vyprvpn.com, it still says my status is “unprotected” and the country I’m connected from is still my origin country and not Japan. Same for whatismyipaddress.com and other.
I am afraid that an answer to this question is not possible without more details, e.g:
what is logged by openvpn or nm-openvpn in /var/log/messages?
“journalctl -b -t nm-openvpn”
Is there an interface tun0: “ip addr show dev tun0”
Which routes are set? “ip -4 route show”
Is there a VPN defined for internet protocol version 4 but is version 6 going out unprotected? “ip -6 route show”
Hope that you are able to get this out of the system (in terminal as root or with “su”)
Mai 16 00:32:39 pc-nobara nm-openvpn[6402]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add ‘–data-ciphers-fallback BF-CBC’ to your configuration and/or add BF-CBC to --data-ciphers.
Mai 16 00:32:39 pc-nobara nm-openvpn[6402]: OpenVPN 2.5.9 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 16 2023
Mai 16 00:32:39 pc-nobara nm-openvpn[6402]: library versions: OpenSSL 3.0.8 7 Feb 2023, LZO 2.10
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: WARNING: No server certificate verification method has been enabled. See How To Guide: Set Up & Configure OpenVPN Client/server VPN | OpenVPN for more info.
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: TCP/UDP: Preserving recently used remote address: [AF_INET]“id address”
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: UDP link local: (not bound)
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: UDP link remote: [AF_INET]“id address”
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: WARNING: ‘link-mtu’ is used inconsistently, local=‘link-mtu 1542’, remote=‘link-mtu 1570’
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: WARNING: ‘auth’ is used inconsistently, local=‘auth SHA1’, remote=‘auth SHA256’
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: WARNING: ‘keysize’ is used inconsistently, local=‘keysize 128’, remote=‘keysize 256’
Mai 16 00:32:40 pc-nobara nm-openvpn[6402]: [eu1.vyprvpn.com] Peer Connection Initiated with [AF_INET]“id address”
Mai 16 00:32:43 pc-nobara nm-openvpn[6402]: TUN/TAP device tun0 opened
Mai 16 00:32:43 pc-nobara nm-openvpn[6402]: /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 6394 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_2 --tun – tun0 1500 1553 “id address” “mask” init
Mai 16 00:32:43 pc-nobara nm-openvpn[6402]: GID set to nm-openvpn
Mai 16 00:32:43 pc-nobara nm-openvpn[6402]: UID set to nm-openvpn
Mai 16 00:32:43 pc-nobara nm-openvpn[6402]: Initialization Sequence Completed
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet “id address” brd “id address” scope global noprefixroute tun0
valid_lft forever preferred_lft forever
inet6 “id address” scope link stable-privacy
valid_lft forever preferred_lft forever
default via “id address” dev tun0 proto static metric 50
default via “id address” dev enp34s0 proto dhcp src “id address” metric 100
“id address” dev tun0 proto kernel scope link src “id address” metric 50
“id address” via “id address” dev enp34s0 proto static metric 50
“id address” dev enp34s0 proto kernel scope link src “id address” metric 100
“id address” dev enp34s0 proto static scope link metric 50
::1 dev lo proto kernel metric 256 pref medium
“my ipv6 adress” dev enp34s0 proto kernel metric 100 pref medium
“my ipv6 adress” dev enp34s0 proto ra metric 100 pref medium
“my ipv6 adress” via “id address” dev enp34s0 proto ra metric 100 pref medium
“id address” dev enp34s0 proto ra metric 100 pref medium
“id address” dev tun0 proto kernel metric 256 pref medium
“id address” dev enp34s0 proto kernel metric 1024 pref medium
default via “id address” dev enp34s0 proto ra metric 100 pref medium
Checked the ip addresses shown in “ip -4/6 router show”. I chose a Dutch server for testing.
The ipv4 address belongs to a Dutch (Netherlands) server, while the ipv6 address shown is mine (that’s why I censored it).
Thanks for the detailed info. There is connection, there is a tun0 interface.
The IPv4 default route goes to the tun interface with higher priority as the original one. There is a dedicated route to the VPN server. Concerning IPv4 it looks fine and it surprises me if your home WAN IPv4 address is displayed in whatismyip.
The IPv6 default route is the Link-Local address of your router which will happily forward it on the internet. But I do not know whether that is the reason of the unprotected status. Simplest test is to temporary set IPv6 method=disabled in NetworkManager for enp34s0.
I do not know about IPv6 support status of VPN providers, some create a trap for IPv6 sometimes resulting in complete loss of internet in Fedora. But this requires a dedicated app outside NetworkManager to set it up.
You can create a duplicate of your normal ethernet connection with ipv6.method=disabled or link-local and autoconnect to your VPN.
The IPv6 is running in parallel with IPv4 and many sites are accessible on both IPv4 and IPv6. OpenVPN and Wireguard are supporting IPv6, but apparently it’s not generally or may be generally not used by VPN providers. Mostly a LAN has addresses which can’t be routed to the internet, but any interface can have IPv6 addresses which can reach the internet, so an IPv6 VPN has to be carefully designed. The same tricks which work on IPv4 work on IPv6 too, so not-routable addresses on the tun0 NATted to providers iPv6 addresses is for sure possible. Good that it works now.