Domain names not resolving on Linux OVPN Client machine

[buzzdriving]

I'm at my wits end trying to track down the cause of this. I've looked at the following possible resolutions and am coming up empty handed.

https://www.dd-wrt.com/phpBB2/viewtopic.php?p=895024
https://askubuntu.com/questions/28733/h ... ccessfully
https://www.linuxquestions.org/question ... 175561975/
https://unix.stackexchange.com/question ... verwritten
https://askubuntu.com/questions/157154/ ... -on-reboot
viewtopic.php?t=20499
https://wiki.debian.org/openvpn%20for%2 ... d%20client
https://wiki.archlinux.org/index.php/Op ... lient_LANs
https://askubuntu.com/questions/946572/ ... h-options1

Specifications
Server
AWS OpenVPN Access Server 2.1.9 instance
Client
Ubuntu 14.04 LTS
OpenVPN Client 2.3.2

When launching openvpn from the command line, I provide it with the following config.

Code: Select all

# Automatically generated OpenVPN client config file
# Generated on Tue Aug 22 03:52:18 2017 by xyz
# Note: this config file contains inline private keys
#       and therefore should be kept confidential!
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=buzzdriving
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=buzzdriving@11.22.33.44/AUTOLOGIN
# OVPN_ACCESS_SERVER_AUTOLOGIN=1
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=11.22.33.44:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# 
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
# OVPN_ACCESS_SERVER_ORGANIZATION=OpenVPN Technologies, Inc.
setenv FORWARD_COMPATIBLE 1
client
server-poll-timeout 4
nobind
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 443 tcp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
dev tun
dev-type tun
ns-cert-type server
reneg-sec 604800
sndbuf 100000
rcvbuf 100000
# NOTE: LZO commands are pushed by the Access Server at connect time.
# NOTE: The below line doesn't disable LZO.
comp-lzo no
verb 3
setenv PUSH_PEER_INFO

<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
</key>

key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----
</tls-auth>

# Extra user-defined configuration
cipher AES-128-CBC
## -----BEGIN RSA SIGNATURE-----
## DIGEST:sha256
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----

The output is as follows:

Code: Select all

Sat Jan 27 03:14:07 2018 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Jun 22 2017
Sat Jan 27 03:14:07 2018 Control Channel Authentication: tls-auth using INLINE static key file
Sat Jan 27 03:14:07 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 27 03:14:07 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 27 03:14:07 2018 Socket Buffers: R=[212992->200000] S=[212992->200000]
Sat Jan 27 03:14:07 2018 UDPv4 link local: [undef]
Sat Jan 27 03:14:07 2018 UDPv4 link remote: [AF_INET]11.22.33.44:1194
Sat Jan 27 03:14:08 2018 TLS: Initial packet from [AF_INET]11.22.33.44:1194, sid=c8a9a16b 22240861
Sat Jan 27 03:14:08 2018 VERIFY OK: depth=1, CN=OpenVPN CA
Sat Jan 27 03:14:08 2018 VERIFY OK: nsCertType=SERVER
Sat Jan 27 03:14:08 2018 VERIFY OK: depth=0, CN=OpenVPN Server
Sat Jan 27 03:14:11 2018 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sat Jan 27 03:14:11 2018 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 27 03:14:11 2018 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sat Jan 27 03:14:11 2018 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 27 03:14:11 2018 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Jan 27 03:14:11 2018 [OpenVPN Server] Peer Connection Initiated with [AF_INET]11.22.33.44:1194
Sat Jan 27 03:14:13 2018 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
Sat Jan 27 03:14:13 2018 PUSH: Received control message: 'PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 12,ping-restart 50,comp-lzo yes,redirect-private def1,redirect-private bypass-dhcp,redirect-private autolocal,redirect-private bypass-dns,route-gateway 111.99.88.9,route 111.99.0.0 255.255.0.0,block-ipv6,ifconfig 111.99.88.77 255.255.255.248'
Sat Jan 27 03:14:13 2018 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.2)
Sat Jan 27 03:14:13 2018 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.2)
Sat Jan 27 03:14:13 2018 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.2)
Sat Jan 27 03:14:13 2018 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:17: block-ipv6 (2.3.2)
Sat Jan 27 03:14:13 2018 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jan 27 03:14:13 2018 OPTIONS IMPORT: explicit notify parm(s) modified
Sat Jan 27 03:14:13 2018 OPTIONS IMPORT: LZO parms modified
Sat Jan 27 03:14:13 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jan 27 03:14:13 2018 OPTIONS IMPORT: route options modified
Sat Jan 27 03:14:13 2018 OPTIONS IMPORT: route-related options modified
Sat Jan 27 03:14:13 2018 ROUTE_GATEWAY 10.0.2.2/255.255.255.0 IFACE=eth0 HWADDR=11:22:33:44:55:66
Sat Jan 27 03:14:13 2018 TUN/TAP device tun0 opened
Sat Jan 27 03:14:13 2018 TUN/TAP TX queue length set to 100
Sat Jan 27 03:14:13 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jan 27 03:14:13 2018 /sbin/ip link set dev tun0 up mtu 1500
Sat Jan 27 03:14:13 2018 /sbin/ip addr add dev tun0 111.99.88.77/29 broadcast 111.99.88.66
Sat Jan 27 03:14:18 2018 ROUTE remote_host is NOT LOCAL
Sat Jan 27 03:14:18 2018 /sbin/ip route add 11.22.33.44/32 via 10.0.2.2
Sat Jan 27 03:14:18 2018 /sbin/ip route add 111.99.0.0/16 via 111.99.88.9 metric 101
Sat Jan 27 03:14:18 2018 Initialization Sequence Completed

This USED to be working, and, in fact, my collaborator's config file still configures his system to receive DNS information correctly since he can connect to AWS EC2 instances by name. I've compared my .ovpn config to his and they are exactly the same apart from the commented out configuration information and the keys. Curiously, he also received the PUSH-OPTIONS errors on the DHCP parameters but this does not cause problems in setting up DNS settings.

Please save me.

[novaflash]

On Linux, DNS is implemented using an external script. Are you calling that script on the command line?

[buzzdriving]

On Linux, DNS is implemented using an external script. Are you calling that script on the command line?

Hi, nova.

Are you referring to /etc/openvpn/update-resolv-conf? If so, then I tried calling it by adding it the client config as described herehttps://askubuntu.com/questions/946572/ ... h-options1.

i.e. I added the following to the client config

Code: Select all

script-security 2 
up /etc/openvpn/update-resolv-conf 
down /etc/openvpn/update-resolv-conf

It didn't work but maybe I put them in the wrong place? Again, my collaborator doesn't seem to have to do any of this.

[novaflash]

I don't know how the other person has his computer configured or how he calls openvpn, so I cannot comment on this.

Regarding the lines, yes, those lines should implement a call to openresolv or resolvconf to implement DNS for you. You will need one of those programs installed and configured for it to work. Why doesn't this work automatically? To put it simply, on Windows, Macintosh, Android, and Apple iOS, there's one proper way to do DNS and so it's easy to program for it and implement it in OpenVPN itself. But for linux there are hundreds of distributions and versions and flavors, so it's left out and an external program handles it instead.

[buzzdriving]

On Linux, DNS is implemented using an external script. Are you calling that script on the command line?

Hi, nova.

Are you referring to /etc/openvpn/update-resolv-conf? If so, then I tried calling it by adding it the client config as described herehttps://askubuntu.com/questions/946572/ ... h-options1.

i.e. I added the following to the client config

Code: Select all

script-security 2 
up /etc/openvpn/update-resolv-conf 
down /etc/openvpn/update-resolv-conf

It didn't work but maybe I put them in the wrong place? Again, my collaborator doesn't seem to have to do any of this.

OK, I dunno what the hell I've done differently, because I definitely tried this in the last couple of days and it didn't work. Now suddenly, it does. As I said, maybe I just put those lines in the wrong place in the config. Regardless, here is my config for anyone else out there who is struggling with the same issue. I'm still puzzled as to why my collaborator's config works unchanged.

Code: Select all

# Automatically generated OpenVPN client config file
# Generated on Tue Aug 22 03:52:18 2017 by xyz
# Note: this config file contains inline private keys
#       and therefore should be kept confidential!
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=buzzdriving
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=buzzdriving@11.22.33.44/AUTOLOGIN
# OVPN_ACCESS_SERVER_AUTOLOGIN=1
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=11.22.33.44:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# 
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
# OVPN_ACCESS_SERVER_ORGANIZATION=OpenVPN Technologies, Inc.
setenv FORWARD_COMPATIBLE 1
client
server-poll-timeout 4
nobind
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 443 tcp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
remote 11.22.33.44 1194 udp
dev tun
dev-type tun
ns-cert-type server
reneg-sec 604800
sndbuf 100000
rcvbuf 100000
# NOTE: LZO commands are pushed by the Access Server at connect time.
# NOTE: The below line doesn't disable LZO.
comp-lzo no
verb 3
setenv PUSH_PEER_INFO
[b]script-security 2 
up /etc/openvpn/update-resolv-conf 
down /etc/openvpn/update-resolv-conf[/b]

<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
</key>

key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----
</tls-auth>

# Extra user-defined configuration
cipher AES-128-CBC
## -----BEGIN RSA SIGNATURE-----
## DIGEST:sha256
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----

[buzzdriving]

I don't know how the other person has his computer configured or how he calls openvpn, so I cannot comment on this.

Regarding the lines, yes, those lines should implement a call to openresolv or resolvconf to implement DNS for you. You will need one of those programs installed and configured for it to work. Why doesn't this work automatically? To put it simply, on Windows, Macintosh, Android, and Apple iOS, there's one proper way to do DNS and so it's easy to program for it and implement it in OpenVPN itself. But for linux there are hundreds of distributions and versions and flavors, so it's left out and an external program handles it instead.

Thanks for pointing me in the right direction. I actually solved the issue before you replied but my post (which is still in moderation) was being tarpitted so I couldn't get it through.

My collaborator's functioning VPN DNS is still a mystery to me because we are working on the same base installation VM, and I set his OVPN client up after mine! In neither of our initial setups did I have to configure the client config to run that script. Nevermind, it's working now, so thanks for the help!