OpenVPN Linux Terminal Ubuntu 20.04 DNS not working.

[Guest]

I've generated my openvpn certs and SSH into my Ubuntu server and run the following command.
 

sudo openvpn AirVPN_Netherlands_UDP-443.ovpn

Sun Jan 23 21:59:00 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4                                                        ] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Sun Jan 23 21:59:00 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Sun Jan 23 21:59:00 2022 NOTE: the current --script-security setting may allow this c                                                        onfiguration to call user-defined scripts
Sun Jan 23 21:59:00 2022 Outgoing Control Channel Authentication: Using 160 bit messa                                                        ge hash 'SHA1' for HMAC authentication
Sun Jan 23 21:59:00 2022 Incoming Control Channel Authentication: Using 160 bit messa                                                        ge hash 'SHA1' for HMAC authentication
Sun Jan 23 21:59:00 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]2                                                        13.152.161.4:443
Sun Jan 23 21:59:00 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Jan 23 21:59:00 2022 UDP link local: (not bound)
Sun Jan 23 21:59:00 2022 UDP link remote: [AF_INET]213.152.161.4:443
Sun Jan 23 21:59:00 2022 TLS: Initial packet from [AF_INET]213.152.161.4:443, sid=ef6                                                        cec32 6366977e
Sun Jan 23 21:59:00 2022 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN                                                        =airvpn.org CA, emailAddress=info@airvpn.org
Sun Jan 23 21:59:00 2022 VERIFY KU OK
Sun Jan 23 21:59:00 2022 Validating certificate extended key usage
Sun Jan 23 21:59:00 2022 ++ Certificate has EKU (str) TLS Web Server Authentication,                                                         expects TLS Web Server Authentication
Sun Jan 23 21:59:00 2022 VERIFY EKU OK
Sun Jan 23 21:59:00 2022 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN                                                        =Alshat, emailAddress=info@airvpn.org
Sun Jan 23 21:59:00 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY13                                                        05_SHA256, 4096 bit RSA
Sun Jan 23 21:59:00 2022 [Alshat] Peer Connection Initiated with [AF_INET]213.152.161                                                        .4:443
Sun Jan 23 21:59:01 2022 SENT CONTROL [Alshat]: 'PUSH_REQUEST' (status=1)
Sun Jan 23 21:59:01 2022 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redi                                                        rect-gateway  def1 bypass-dhcp,dhcp-option DNS 10.7.232.1,route-gateway 10.7.232.1,to                                                        pology subnet,ping 10,ping-restart 60,ifconfig 10.7.232.45 255.255.255.0,peer-id 10,c                                                        ipher AES-256-GCM'
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: compression parms modified
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: route options modified
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: route-related options modified
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modi                                                        fied
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: peer-id set
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: adjusting link_mtu to 1625
Sun Jan 23 21:59:01 2022 OPTIONS IMPORT: data channel crypto options modified
Sun Jan 23 21:59:01 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Jan 23 21:59:01 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with                                                         256 bit key
Sun Jan 23 21:59:01 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with                                                         256 bit key
Sun Jan 23 21:59:01 2022 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=                                                        38:d5:47:b5:d1:ca
Sun Jan 23 21:59:01 2022 TUN/TAP device tun0 opened
Sun Jan 23 21:59:01 2022 TUN/TAP TX queue length set to 100
Sun Jan 23 21:59:01 2022 /sbin/ip link set dev tun0 up mtu 1500
Sun Jan 23 21:59:01 2022 /sbin/ip addr add dev tun0 10.7.232.45/24 broadcast 10.7.232                                                        .255
Sun Jan 23 21:59:01 2022 /etc/openvpn/update-resolv-conf tun0 1500 1553 10.7.232.45 2                                                        55.255.255.0 init
Sun Jan 23 21:59:06 2022 /sbin/ip route add 213.152.161.4/32 via 192.168.0.1
Sun Jan 23 21:59:06 2022 /sbin/ip route add 0.0.0.0/1 via 10.7.232.1
Sun Jan 23 21:59:06 2022 /sbin/ip route add 128.0.0.0/1 via 10.7.232.1
Sun Jan 23 21:59:06 2022 Initialization Sequence Completed

However, the DNS does not work and the machine cannot connect to the Internet.
 

Resolving ifconfig.co (ifconfig.co)... failed: Temporary failure in name resolution

What do I have to do to fix it?
 

[OpenSourcerer 1441]

1 hour ago, unv said:

Sun Jan 23 21:59:01 2022 /etc/openvpn/update-resolv-conf tun0 1500 1553 10.7.232.45 2 55.255.255.0 init

Interesting line, that script seems like something Debian packages into the openvpn package while at least Arch Linux doesn't. I've found mentions of this script in the Arch Linux wiki, though: It's supposed to update /etc/resolv.conf with network options pushed by the server. If one believes the line, the detected DNS server is 10.7.232.45 – but that is not a DNS server address, it's the local tun0 address. Maybe that's all there is to it.
To check on that, connect, then look into the contents of /etc/resolv.conf; maybe paste here, if you want. If there's a nameserver 10.7.232.45 line, that is indeed the problem. If the address is correctly 10.7.232.1, the problem lies somewhere else.

[Guest]

Hi, thanks for the reply.
 

# 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 "resolvectl 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
options edns0 trust-ad

[OpenSourcerer 1441]

Interesting. Either the file is updated but overridden right away or not updated at all. In any case, if you still want to manage DNS automagically, you need a different script (as the wiki article outlines). Follow the steps on the Arch wiki, but leave out the PolicyKit rule.

Someone should probably notify the maintainer of the Ubuntu openvpn package that a script is blindly copied from Debian.

[Guest]

1 hour ago, OpenSourcerer said:

Interesting. Either the file is updated but overridden right away or not updated at all. In any case, if you still want to manage DNS automagically, you need a different script (as the wiki article outlines). Follow the steps on the Arch wiki, but leave out the PolicyKit rule.

Someone should probably notify the maintainer of the Ubuntu openvpn package that a script is blindly copied from Debian.

Thanks, I'll let you know how I get on!

[Guest]

Hi, I'm still struggling to get this working, should I just wait until AirVPN fix the issue?
 

5 hours ago, OpenSourcerer said:

Interesting. Either the file is updated but overridden right away or not updated at all. In any case, if you still want to manage DNS automagically, you need a different script (as the wiki article outlines). Follow the steps on the Arch wiki, but leave out the PolicyKit rule.

Someone should probably notify the maintainer of the Ubuntu openvpn package that a script is blindly copied from Debian.

Thanks, I'll let you know how I get on!

[OpenSourcerer 1441]

5 hours ago, unv said:

Hi, I'm still struggling to get this working, should I just wait until AirVPN fix the issue?

It's an issue with the OpenVPN scripts, not with anything owned or operated by AirVPN. I thought that much was clear.
If you're stuck, do tell where.

[Guest]

Update.

I installed the Eddie client and used it via the command line and everything is working fine!

[OpenSourcerer 1441]

Hm, somehow your posts implied it wasn't an option, so I didn't even recommend it. But that's a way to solve it, of course.