OpenVPN routing: multiple default entries. OpenVPN client: iptables. DNS issues

Question

I'm running an OpenVPN-Server (Debian 8) for privacy purposes when using public wifi. Hence, all network traffic of the client is intended to be handled over the VPN connection. The server and client config is given below.

Server config:

port 1194
proto tcp
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt    
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-auth /etc/openvpn/tlsauth.key 0

user nobody
group nogroup

server 10.11.12.0 255.255.255.0

ifconfig-pool-persist ipp.txt
keepalive 10 120

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

persist-key
persist-tun

comp-lzo
status openvpn-status.log
verb 3

Client config:

client
remote X.X.X.X 1194
proto tcp

dev tun

resolv-retry-infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt    
key /etc/openvpn/client.key
tls-auth /etc/openvpn/tlsauth.key 0

comp-lzo 0
verb 2

When the VPN service is started on the client, the routing table is altered as given below.

Routing Table (192.168.178.0/24 denotes the public wifi):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.11.12.13     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    1024   0        0 wlan0
10.11.12.1      10.11.12.13     255.255.255.255 UGH   0      0        0 tun0
10.11.12.13     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.11.12.13     128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0
X.X.X.X         192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0

The relevant section of the syslog when starting openvpn:

ovpn-client[3395]: OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
ovpn-client[3395]: library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08    
ovpn-client[3395]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
ovpn-client[3395]: Control Channel Authentication: using '/etc/openvpn/tlsauth.key' as a OpenVPN static key file
ovpn-client[3395]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3395]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
ovpn-client[3396]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:1194 [nonblock]
ovpn-client[3396]: TCP connection established with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TCPv4_CLIENT link local: [undef]
ovpn-client[3396]: TCPv4_CLIENT link remote: [AF_INET]X.X.X.X:1194
ovpn-client[3396]: VERIFY OK: depth=1, [...]
ovpn-client[3396]: VERIFY OK: depth=0, [...]
ovpn-client[3396]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
ovpn-client[3396]: [VPN-Server] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TUN/TAP device tun0 opened
ovpn-client[3396]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
ovpn-client[3396]: /sbin/ip link set dev tun0 up mtu 1500
NetworkManager[556]: <info> (tun0): carrier is OFF
NetworkManager[556]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 15)
NetworkManager[556]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/14
ovpn-client[3396]: /sbin/ip addr add dev tun0 local 10.11.12.14 peer 10.11.12.13
NetworkManager[556]: <info> (tun0): link connected
ovpn-client[3396]: ERROR: Linux route add command failed: external program exited with error status: 2
ovpn-client[3396]: GID set to nogroup
ovpn-client[3396]: UID set to nobody
ovpn-client[3396]: Initialization Sequence Completed
NetworkManager[556]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[556]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[556]: <info> Activation (tun0) starting connection 'tun0'
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[556]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[556]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[556]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[556]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[556]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[556]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[556]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[556]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[556]: <info> Activation (tun0) successful, device activated.

My questions are:

Is the routing table correct? For me, it looks somewhat strange due to the two default entries. Furthermore, when recording the traffic on the public wifi router (using tcpdump), not all traffic is routed over VPN.
What does the error (ERROR: Linux route add command failed: external program exited with error status: 2) in the syslog say? Is it maybe conneted to the first question?

Edit: Thanks for the answer, Michal. In order to cut down the multicast/local/... traffic, I'm additionally planning to use iptables to drop that traffic, too.

I'm trying to use iptables rules as follows:

#!/bin/bash

GATEWAY="192.168.178.1"

iptables -F

# Allow loopback device (internal communication)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow DHCP communication with gateway
iptables -A INPUT -i wlan0 -p udp -s $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p udp -d $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT

# Allow ICMP communication with gateway
iptables -A INPUT -i wlan0 -p icmp -s $GATEWAY/32 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p icmp -d $GATEWAY/32 -j ACCEPT

#Allow VPN establishment
iptables -A OUTPUT -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -p tcp --sport 1194 -j ACCEPT

#Accept all TUN connections (tun = VPN tunnel)
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT

#Set default policies to drop all communication unless specifically allowed
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

IMO, these rules should be sufficient to get an IP assigned by the gateway, establish a connection to the OpenVPN server and handle all traffic over that connection. But, DNS does not work, although it is also supposed to use the VPN connection. Why isn't that working?

Next edit: Set up a local nameserver (dnsmasq) on the VPN server. The server config changed to

push "dhcp-option DNS 10.11.12.1"

instead of

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

When running dig +short serverfault.com @10.11.12.1 on the VPN server itself, the hostname could successfully be retrieved. If the command is run on a different host not using VPN (dig +short stackoverflow.com @X.X.X.X), the hostname could also successfully be retrieved. However, when the command ist run on a client connected to the VPN (dig +short stackoverflow.com @10.11.12.1), the command fails (;; connection timed out; no servers could be reached). Why? Iptables are set to ACCEPT all.

Lot's of problems here. Let me edit my answer. – Michal Sokolowski May 18 '15 at 07:24 — Michal Sokolowski, May 18 '15 at 07:24

Michal Sokolowski · Accepted Answer · 2015-05-18T08:06:11.610

Routing table looks okay, look at metric column. Route with the lowest metric will be preferred. Your routing table contains now two default routes and 10.11.12.13 will be preferred over 192.168.178.1 because of lower metric. About the traffic on physical interface; this is also normal because you have listening services which respond for broadcast/multicast traffic. This traffic cannot go via VPN interface. This is also a sign of some applications which use local network to speed up things, for instance: dropbox, teamviewer, upnp, microsoft network neighborhood and many many other functionalities.
That most probably 'cos /sbin/route or /usr/sbin/route haven't had permission to do something, because you used directive in your config files to drop openvpn's service privileges to user nobody, after reconnect it can yell about such things. Especially when you change config of the server and don't restart client manually with full privileges. That's also normal.

PS. You don't need resolv-retry-infinite if you use remote with IP address, it makes no sense.

EDIT: iptables configutation I assume that's cleint's iptables configuration.

You should flush NAT table as well:

iptables -F -t nat

You don't need rules for DHCP communication because of two reasons:
- DHCP services usually use so called raw sockets which are not covered by iptables (last time I check it, dhcpd, dhcpcd were using it),
- DHCP mechanism is implemented in OpenVPN protocol, so there isn't any actual DHCP communication, I mean DHCP Rrequest, DHCP offer, DHCP ACK, DHCP Pack.
Using OpenVPN in TCP mode is bad idea: http://sites.inka.de/bigred/devel/tcp-tcp.html
Please edit your question and tell me if:
- are you able to ping VPN server (VPN IP address) from client (tunnel communication)
- show me netstat -l -u -n -p from the server (we need to know if your dnsmasq daemon is listening on tun interface),
- are you able to ping 8.8.8.8 after VPN was established?

Thanks again, Michal. Didn't know about the raw sockets. The DNS problem occured due to the entries in `/etc/resolv.conf`, where the DNS information gets stored after a DHCP lease. Since the DNS server is set to the gateway of the open wifi and communication is blocked to that mchine via iptables, DNS didn't work. Solved the problem by adding a nameserver entry to `/etc/resolvconf/resolv.conf.d/head` which is then handled over the VPN connection. Thus `dnsmasq` isn't required at all. — user236012, May 18 '15 at 10:26

OpenVPN routing: multiple default entries. OpenVPN client: iptables. DNS issues

1 Answers1