DNS doesn't work after connecting via openvpn on Linux

[omnikai 0]

Hi all,

 

First-time poster with a real head-scratcher (to me, probably obvious to others).

 

I'm trying to set up a server on Google Compute Engine with AirVPN. I created a Ubuntu 16 VM from scratch, installed OpenVPN, generated a config and ran sudo openvpn config.ovpn (I renamed the config file).

 

By all appearances this works fine. I lose my connection (as expected) and can reconnect via the Persei external IP through a forwarded port to 22 over SSH. Great, right?

 

However I can't ping anything, can't connect to any repos via apt-get, can't do anything on the internet at all really. After some investigation I find that I can ping IPs, but can't ping any domain names or use nslookup. Ok, DNS is messed up, but no idea why...

 

In trying to fix this, I realize I also can't use sudo for anything. Just using sudo nano /etc/rc.local to alter a file, for example, results in the terminal doing nothing (cursor goes to new line, but no output). I can Ctrl-C to escape though.

 

Note: This weird sudo issue didn't happen when I tried this same process on Debian Jesse, however the DNS problem did. I also tried using the AirVPN-provided openvpn binary, but all the same problems occurred.

 

So I'm stuck. I've built servers before (on Digital Ocean) with ubuntu and didn't run into this weird DNS/Sudo problem.

 

Here's my config sans certs, but I didn't change a single line from what AirVPN generated.

client
dev tun
proto udp
remote 94.100.23.162 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
route-delay 5
verb 3
explicit-exit-notify 5

Any help this community can provide would be much appreciated!

[NaDre 154]

What is in /etc/resolv.conf? Probably the IP of the DNS server google provides, which will refuse connections coming from the AirVPN exit address.

 

If you are using the 10.4.0.0/16 subnet (UDP on port 443) then put 10.4.0.1 at the top of /etc/resolv.conf, as a quick and dirty way to do this.

 

Then maybe see this:

 

https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/

[omnikai 0]

Thanks for the response!

 

/etc/resolv.conf has this:

domain c.skyraker-1374.internal.
search c.skyraker-1374.internal. google.internal.
nameserver 169.254.169.254

I'll try changing the nameserver I guess?

 

Or should I add this to my config file as per that link you provided?

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

Thanks again!

[omnikai 0]

Alright, changing /etc/resolv.conf to "nameserver 10.4.0.1" and starting openvpn did the trick! I can ping google.com now 

 

Unless there's any reason why I shouldn't continue using this solution, I'm good. Thanks so much!

[NaDre 154]

Alright, changing /etc/resolv.conf to "nameserver 10.4.0.1" and starting openvpn did the trick! I can ping google.com now 

 

Unless there's any reason why I shouldn't continue using this solution, I'm good. Thanks so much!

 

Does /etc/resolv.conf get overwritten again when you reboot? The DHCP client may do this?

 

...

I lose my connection (as expected) and can reconnect via the Persei external IP through a forwarded port to 22 over SSH. Great, right?

...

 

If you make a routing (and maybe iptables) change before starting the OpenVPN client, you can avoid this. See the "UPDATE" at the end of this:

 

https://airvpn.org/topic/12274-ubuntu-vm-cant-connect-through-openvpn/?p=44812

 

Here is that part again:

 

...

 

UPDATE:

 

For completeness, the comments below may help demonstrate what the issue is.

 

As quick and dirty way to sustain the SSH connection, add a routing table entry to direct traffic to your SSH client over the original gateway. Something like this:

sudo route add -host 111.222.333.444 gw 555.666.777.1

There, "111.222.333.444" would be the address you connected from (as shown when you do "echo $SSH_CLIENT"), and "555.666.777.1" is the original default gateway (the entry with a "Genmask" of "0.0.0.0" when you do "/sbin/route -n").

 

SSH connections from anywhere else will still fail.

 

===

 

UPDATE 2:

 

I did not actually explain the problem above. The problem is that the default gateway gets changed by OpenVPN, and that breaks your current SSH connection unless you set up appropriate routes before you start OpenVPN.

 

Here is a more general purpose solution than what was in "UPDATE" above.

 

It is assumed here that the default gateway interface before OpenVPN is started is "eth0". This is the usual convention

for Linux systems.

 

It should ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection back on eth0 again.

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412

UPDATE to UPDATE 2:

 

The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412

There "12.345.67.89" must be the original non-VPN gateway.