Cfxtrjtrk

I have set up an openvpn VPN on my ubuntu laptop, and everything seemed to be working fine, but when I connect my IP address does not change. I have tried to use the same procedure on my Mac (using a third-party software to load the client.ovpn) and everything works fine. Could you please help undrstanding what's going wrong?
If I open a terminal and connect from my openvpn client, this is the full message I get:

Mon Jan  7 11:53:59 2019 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep  5 2018

Mon Jan  7 11:53:59 2019 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08

Mon Jan  7 11:53:59 2019 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

Mon Jan  7 11:53:59 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Jan  7 11:53:59 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Jan  7 11:53:59 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]185.21.216.152:1194

Mon Jan  7 11:53:59 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]

Mon Jan  7 11:53:59 2019 UDP link local: (not bound)

Mon Jan  7 11:53:59 2019 UDP link remote: [AF_INET]185.21.216.152:1194

Mon Jan  7 11:53:59 2019 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay

Mon Jan  7 11:53:59 2019 TLS: Initial packet from [AF_INET]185.21.216.152:1194, sid=75702836 ec665d46

Mon Jan  7 11:53:59 2019 VERIFY OK: depth=1, C=UK, ST=Ceredigion, L=Aberystwyth, O=Feral Hosting, CN=Feral Hosting CA, emailAddress=support@feralhosting.com

Mon Jan  7 11:53:59 2019 VERIFY OK: nsCertType=SERVER

Mon Jan  7 11:53:59 2019 VERIFY OK: depth=0, C=UK, ST=Ceredigion, L=Aberystwyth, O=Feral Hosting, CN=nyx, emailAddress=support@feralhosting.com

Mon Jan  7 11:53:59 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Mon Jan  7 11:53:59 2019 [nyx] Peer Connection Initiated with [AF_INET]185.21.216.152:1194

Mon Jan  7 11:54:00 2019 SENT CONTROL [nyx]: 'PUSH_REQUEST' (status=1)

Mon Jan  7 11:54:00 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.32.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.32.0.90 10.32.0.89,peer-id 3,cipher AES-256-GCM'

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: timers and/or timeouts modified

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: --ifconfig/up options modified

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: route options modified

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: peer-id set

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: adjusting link_mtu to 1625

Mon Jan  7 11:54:00 2019 OPTIONS IMPORT: data channel crypto options modified

Mon Jan  7 11:54:00 2019 Data Channel: using negotiated cipher 'AES-256-GCM'

Mon Jan  7 11:54:00 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Jan  7 11:54:00 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Jan  7 11:54:00 2019 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=wlp2s0 HWADDR=20:16:d8:c7:61:09

Mon Jan  7 11:54:00 2019 TUN/TAP device tun0 opened

Mon Jan  7 11:54:00 2019 TUN/TAP TX queue length set to 100

Mon Jan  7 11:54:00 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

Mon Jan  7 11:54:00 2019 /sbin/ip link set dev tun0 up mtu 1500

Mon Jan  7 11:54:00 2019 /sbin/ip addr add dev tun0 local 10.32.0.90 peer 10.32.0.89

Mon Jan  7 11:54:00 2019 /sbin/ip route add 185.21.216.152/32 via 192.168.0.1

Mon Jan  7 11:54:00 2019 /sbin/ip route add 0.0.0.0/1 via 10.32.0.89

Mon Jan  7 11:54:00 2019 /sbin/ip route add 128.0.0.0/1 via 10.32.0.89

Mon Jan  7 11:54:00 2019 /sbin/ip route add 10.32.0.1/32 via 10.32.0.89

Mon Jan  7 11:54:00 2019 GID set to nogroup

Mon Jan  7 11:54:00 2019 UID set to nobody

Mon Jan  7 11:54:00 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

Mon Jan  7 11:54:00 2019 Initialization Sequence Complete

the client config file is the same I've used on the Mac, so it should be correctly populated.

The client.ovpn file I'm using is as follows:

client

dev tun

remote <myhostdomain> 1194

proto udp

resolv-retry infinite

nobind



# On non-Windows systems, please uncomment the following for added security:

user nobody

group nogroup



persist-key

persist-tun



ca keys/ca.crt

cert keys/myuser.crt

key keys/myuser.key

tls-auth keys/tls-auth.key 1



ns-cert-type server

comp-lzo



# Log file verbosity

verb 3

# Silence repeating messages

mute 20

Any ideas?

Thank you

output of ls -al /etc/resolv.conf :

lrwxrwxrwx 1 root root 39 Jan  7 09:14 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

output of cat /etc/resolv.conf :

# This file is managed by man:systemd-resolved(8). Do not edit.

#

# This is a dynamic resolv.conf file for connecting local clients to the

# internal DNS stub resolver of systemd-resolved. This file lists all

# configured search domains.

#

# Run "systemd-resolve --status" to see details about the uplink DNS servers

# currently in use.

#

# Third party programs must not access this file directly, but only through the

# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,

# replace this symlink by a static file or a different symlink.

#

# See man:systemd-resolved.service(8) for details about the supported modes of

# operation for /etc/resolv.conf.



nameserver 127.0.0.53

search Home

output of ps auxc | grep -i dns : no output at all

ouput of ps auxc | grep -i resolv :

systemd+   612  0.0  0.0  71120  2440 ?        Ss   17:39   0:09 systemd-resolve

Your symlink for /etc/resolv.conf is incorrect.

ls -al /etc/resolv.conf shows us:

resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

which is incorrect. It should point to resolv.conf, like so:

resolv.conf -> /run/systemd/resolve/resolv.conf

so...

sudo rm -i /etc/resolv.conf # remove the incorrect symlink



sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf # recreate it correctly

then make sure that ls -al /etc/resolv.conf looks correct. cat /etc/resolv.conf should show a different result than you had before... probably 192.168.x.1 (your router) or another dns server address (probably from your VPN provider).

Update #1:

Add this at the end of your .ovpn file, then sudo openvpn client_file, and see if /etc/resolv.conf changes with/without VPN.

script-security 2

up /etc/openvpn/update-resolv-conf

down /etc/openvpn/update-resolv-conf

Update #2:

DNS is messed up in Ubuntu 18.xx. OpenVPN behaves differently if started from the terminal command line, vs via Network Manager.

As per my previous instruction, make the changes to the /etc/resolv.conf symlink, and add the up/down script changes to your .ovpn file.

At this point, if you use sudo openvpn client.ovpn, the VPN tunnel will be created, but /etc/resolv.conf will not get properly updated, and you'll have dns leaks. DNS leaks can be seen at either http://dnsleak.com or http://dnsleaktest.com.

Observe the contents of /etc/resolv.conf by typing cat /etc/resolv.conf. It should probably contain something similar to 192.168.x.1, the address of your router.

Create a new Network Manager VPN connection script. Import your .ovpn file like so:

After ADDing the imported script, connect to your desired VPN server by going to the Network Manager menu (top panel, right corner), select VPN, and then select the VPN connection script that you added earlier.

Again, observe the contents of /etc/resolv.conf, and it now should contain the IP address of your VPN's DNS server.

Go to http://dnsleak.com, and confirm that it correctly shows your new IP address, and click the START button to confirm that you don't have any dns leaks.