Custom OpenVPN killswitch problem

[pearsimmon]

I'm having trouble setting up a killswitch for a given OpenVPN config file. Basically, I want all connections outside of VPN to be dropped, except loopback and local subnet.

I was experimenting with this free OpenVPN config: https://www.freeopenvpn.org/en/cf/russia.php
By itself, without further configuration, this VPN works fine and changes my IP address.

I searched the Internet for solutions and have already tried three different aproaches.

First approach with "openvpn" group. This one actually doesn't account for local subnet, but let's let that slide for now.

First, change iptables rules:

Code: Select all

# add system group
sudo groupadd -r openvpn

# flush tables
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP
sudo iptables -F

# let vpn talk to internet
sudo iptables -A OUTPUT -j ACCEPT -m owner --gid-owner openvpn

# allow loopback
sudo iptables -A OUTPUT -j ACCEPT -o lo
sudo iptables -A OUTPUT -j ACCEPT -o tun+

# permit established connections
sudo iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED

# refuse all by default
sudo iptables -P OUTPUT DROP
sudo iptables -P INPUT DROP

Then add or modify "dev tun" and "group openvpn" to the .ovpn file, and start OpenVPN with "sudo openvpn --config /path/to/config.ovpn". Unfortunately, I get the following error:

Code: Select all

write UDP: Operation not permitted (code=1)

and Internet doesn't work at all.

Second approach using iptables rules, hardcoding VPN's IP address:

Code: Select all

sudo iptables --flush
sudo iptables --delete-chain
sudo iptables -t nat --flush
sudo iptables -t nat --delete-chain
sudo iptables -P OUTPUT DROP
sudo iptables -A INPUT -j ACCEPT -i lo
sudo iptables -A OUTPUT -j ACCEPT -o lo
sudo iptables -A INPUT --src 192.168.0.0/24 -j ACCEPT -i eth0
sudo iptables -A OUTPUT -d 192.168.0.0/24 -j ACCEPT -o eth0
sudo iptables -A OUTPUT -j ACCEPT -d 46.48.181.129 -o eth0 -p udp -m udp --dport 1195
sudo iptables -A INPUT -j ACCEPT -s 46.48.181.129 -i eth0 -p udp -m udp --sport 1195
sudo iptables -A INPUT -j ACCEPT -i tun0
sudo iptables -A OUTPUT -j ACCEPT -o tun0

Note: this time, I used "dev tun0" instead of "dev tun".
The error doesn't appear, openvpn's output looks successful, but even then Internet or simple "ping" to google.com don't work at all (I replaced MAC address in the log with <snip>):

Code: Select all

Thu Jul  4 17:10:38 2019 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 14 2018
Thu Jul  4 17:10:38 2019 library versions: OpenSSL 1.0.2s  28 May 2019, LZO 2.08
Thu Jul  4 17:10:38 2019 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Jul  4 17:10:38 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]46.48.181.129:1195
Thu Jul  4 17:10:38 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Jul  4 17:10:38 2019 UDP link local: (not bound)
Thu Jul  4 17:10:38 2019 UDP link remote: [AF_INET]46.48.181.129:1195
Thu Jul  4 17:10:38 2019 TLS: Initial packet from [AF_INET]46.48.181.129:1195, sid=90935a47 cc10d71f
Thu Jul  4 17:10:39 2019 VERIFY OK: depth=2, C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Thu Jul  4 17:10:39 2019 VERIFY OK: depth=1, C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Thu Jul  4 17:10:39 2019 VERIFY OK: depth=0, OU=Domain Control Validated, OU=PositiveSSL Wildcard, CN=*.opengw.net
Thu Jul  4 17:10:39 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Jul  4 17:10:39 2019 [*.opengw.net] Peer Connection Initiated with [AF_INET]46.48.181.129:1195
Thu Jul  4 17:10:40 2019 SENT CONTROL [*.opengw.net]: 'PUSH_REQUEST' (status=1)
Thu Jul  4 17:10:41 2019 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.211.1.97 10.211.1.98,dhcp-option DNS 10.211.254.254,dhcp-option DNS 8.8.8.8,route-gateway 10.211.1.98,redirect-gateway def1'
Thu Jul  4 17:10:41 2019 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jul  4 17:10:41 2019 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul  4 17:10:41 2019 OPTIONS IMPORT: route options modified
Thu Jul  4 17:10:41 2019 OPTIONS IMPORT: route-related options modified
Thu Jul  4 17:10:41 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jul  4 17:10:41 2019 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Jul  4 17:10:41 2019 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul  4 17:10:41 2019 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Jul  4 17:10:41 2019 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul  4 17:10:41 2019 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=eth0 HWADDR=<snip>
Thu Jul  4 17:10:41 2019 TUN/TAP device tun0 opened
Thu Jul  4 17:10:41 2019 TUN/TAP TX queue length set to 100
Thu Jul  4 17:10:41 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Jul  4 17:10:41 2019 /sbin/ip link set dev tun0 up mtu 1500
Thu Jul  4 17:10:41 2019 /sbin/ip addr add dev tun0 local 10.211.1.97 peer 10.211.1.98
Thu Jul  4 17:10:41 2019 /sbin/ip route add 46.48.181.129/32 via 192.168.0.1
Thu Jul  4 17:10:41 2019 /sbin/ip route add 0.0.0.0/1 via 10.211.1.98
Thu Jul  4 17:10:41 2019 /sbin/ip route add 128.0.0.0/1 via 10.211.1.98
Thu Jul  4 17:10:41 2019 Initialization Sequence Completed

On to the third approach - ufw-based:

Code: Select all

sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow in on tun0
sudo ufw allow out on tun0
sudo ufw allow in on eth0 from 192.168.0.0/24
sudo ufw allow out on eth0 to 192.168.0.0/24
sudo ufw allow out on eth0 to 46.48.181.129 port 1195 proto udp
sudo ufw allow in on eth0 from 46.48.181.129 port 1195 proto udp
sudo ufw enable

As you can guess, same thing as with iptables: output seemingly OK, but no Internet.

What am I doing wrong?

[timkb4cq]

I'm no expert on iptables, but to access the Web you do need to enable tcp as well as udp. In that last example you only allow udp from & to the VPN address (I'm assuming 46.48.181.129 is the VPN).

[pearsimmon]

That did it, the "ufw" approach now works correctly. But I wonder why the first approach doesn't work? It looked very promising because it does not require manually resolving and then hardcoding IP addresses for each config file.

---edit:

After some insight, the issue in first approach is almost definitely in this line:

Code: Select all

sudo iptables -A OUTPUT -j ACCEPT -m owner --gid-owner openvpn

Relevant: https://unix.stackexchange.com/a/413835
I'll try his solution in free time.

[pearsimmon]

the issue in first approach is almost definitely in this line:

Code: Select all

sudo iptables -A OUTPUT -j ACCEPT -m owner --gid-owner openvpn

Relevant: https://unix.stackexchange.com/a/413835

So it seems it's a bug in iptables's extension. Does someone have an idea how to apply this solution in most clean way, without creating unnecessary new users?

[pearsimmon]

Sorry to bump this, but I found a solution for the gid-owner approach.
It turns out 'iptables' checks only if a given group is user's primary, but won't work if a user merely belongs (branches out) to this group. So since 'openvpn' must be run with 'sudo', I had to change root's primary group to 'openvpn'. Now the killswitch works fine.

Question is, is it safe to change root's primary group? Will it break something in the long run? Another way would be to run 'openvpn' as different user, but not even '--user' flag or 'user (...)' entry in .ovpn file solves this accurately.