Whonix-13-Workstation VPN-Firewall

entr0py · May 19, 2016, 6:17am

Instructions tested and working (with vpn-specific required modifications to openvpn.conf): Connecting to Tor before a VPN

Fail-closed tests with:

WORKSTATION_FIREWALL=1
TUNNEL_FIREWALL_ENABLE=true

| TransPort | TUNNEL_FIREWALL_ALLOW_LOCAL_NET |
|  traffic  |      true      |     false      |
|___________|________________|________________|
|           |                |                |
|  VPN Up   |    allowed     |    allowed     |
|           |                |                |
|  VPN Down |    blocked     |    blocked     |
|___________|________________|________________|


| SocksPort | TUNNEL_FIREWALL_ALLOW_LOCAL_NET |
|  traffic  |      true      |     false      |
|___________|________________|________________|
|           |                |                |
|  VPN Up   |    allowed     |    blocked     |
|           |                |                |
|  VPN Down |    allowed     |    blocked     |
|___________|________________|________________|

Working as expected (by me anyway).

Notes:

Not sure why VPN_FIREWALL= is still in conf file. Would like confirmation that it is obsolete and replaced by TUNNEL_FIREWALL_ENABLE?
With all the changes to root filesystem, really need bind-directories functionality for this (in Qubes). (as noted in wiki) (Not interested in standalone vm’s)
As a temporary workaround, would like to keep openvpn files in ~/openvpn/ and launch manually (not use systemd).
With my limited linux knowledge, can’t figure out why:

su tunnel
sudo openvpn openvpn.conf

ROUTE_GATEWAY 10.137.2.1
TUN/TAP device tun0 opened

works but

sudo -u tunnel openvpn openvpn.conf
=
ROUTE_GATEWAY 10.137.2.1
ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
Exiting due to fatal error

fails to create tun device.

Patrick · May 19, 2016, 1:53pm

Thank you a lot for testing this!

Yes, very much the same.

The config file comments should be cleaned up for next release indeed. My motivation was to keep the old config variable name to avoid confusing existing users. [On the gateway, and then copy pasted this legacy to the workstation.] Are you interested to send a git pull request improving that?

Yes.

I have changed /etc/whonix_firewall.d/50_user.conf to /rw/config/whonix_firewall.d/50_user.conf so at least that does not require bind-dirs.

Please test and confirm it works.

sudo mv /etc/whonix_firewall.d/50_user.conf /rw/config/whonix_firewall.d/50_user.conf

It is very hairy indeed to make openvpn run under a user account.

“You need to emulate usability-misc/50_unpriv.conf at master · Kicksecure/usability-misc · GitHub then.”

sudo /usr/sbin/openvpn --rmtun --dev tun0
sudo /usr/sbin/openvpn --mktun --dev tun0 --dev-type tun --user tunnel --group tunnel
cd /etc/openvpn
sudo -u tunnel openvpn openvpn.conf

off-topic, you might also be interested in:

entr0py · May 20, 2016, 6:11am

Works!

If there is no plan to permanently replace usage of VPN_FIREWALL with TUNNEL_FIREWALL_ENABLE, probably makes sense to keep TUNNEL_FIREWALL_ENABLE hidden. Advantages to using VPN_FIREWALL: 1) legacy benefits 2) consistency with gateway-vpn-firewall.

Also, for consistency, configurable booleans should all be 0/1 or all true/false…

https://github.com/Whonix/whonix-ws-firewall/blob/master/usr/bin/whonix_firewall#L28

VPN-Firewall can function with WORKSTATION_FIREWALL=0! This seems counterintuitive since VPN-Firewall is a feature / subset of the Workstation Firewall? And is behaving as if WORKSTATION_FIREWALL=1 anyway.

In both Gateway & Workstation /usr/bin/whonix_firewall:

When defining local network ranges, it’s written as:

A: “xx.xx.xx.0-xx.xx.xx.24”

https://github.com/Whonix/whonix-gw-firewall/blob/master/usr/bin/whonix_firewall#L136-L181
https://github.com/Whonix/whonix-ws-firewall/blob/master/usr/bin/whonix_firewall#L148-L171

In Whonix 11 these same ranges were defined as:

B: “xx.xx.xx.0/24”

https://github.com/Whonix/whonix-gw-firewall/blob/Whonix11/usr/bin/whonix_firewall#L122

Since A != B, shouldn’t A be written as:

A: “xx.xx.xx.0-xx.xx.xx.255” ?

entr0py · May 20, 2016, 6:14am

#########################################
## VPN-Firewall Settings (WORKSTATION) ##
#########################################

## VPN-Firewall enforces more leak-resistant firewall rules while connected 
## to VPNs. It also acts as a fail-closed mechanism should the VPN lose its
## connection.
##
## ENABLE(1) to require all traffic to be tunneled through your VPN upon 
## exiting the Tor network.
##     user -> tor -> vpn -> destination
## Should the VPN lose its connection, all traffic will be halted.
## A 3rd Party VPN Provider is REQUIRED to enable this option.
##
## DISABLE(0) (Default) to route traffic through the VPN when possible.
## Traffic will continue to flow through Tor even if the VPN connection
## is unavailable.
## 
VPN_FIREWALL=0

## VPN-Firewall OPTIONAL Settings to BYPASS VPN
##   (These settings only take effect when VPN_FIREWALL is ENABLED above)
##   WARNING: These settings can result in network traffic through Tor
##            even when VPN connectivity is disabled! Use Caution!
## 
## Allow connections to LOCAL_NET (see Advanced Options below)
## Many Whonix applications are pre-configured to access the Tor network
## directly and ignore any user configured proxies, including VPN, Socks, etc.
##     user -> tor -> destination
## These include Tor Browser, curl, wget, git and others. They require
## direct access to the Local Network to communicate.
##
## This setting is DISABLED(false) by Default meaning all pre-configured
## applications will cease working while VPN-Firewall is enabled, unless 
## they are manually re-configured.
##
## ENABLE(true) this setting if you wish for these applications to remain
## functional regardless of the state of the VPN connection. WARNING: These
## applications will continue to route traffic over Tor even when the
## VPN is disconnected!
##
TUNNEL_FIREWALL_ALLOW_LOCAL_NET=false

## Allow additional programs to BYPASS the VPN
## DISABLED(false) by Default. Since these programs require direct connections 
## to the Tor network, they will not function at all while VPN-Firewall 
## is enabled.
## ENABLE(true) this setting to allow these programs to access the Tor network
## and continue to do so regardless of the status of the VPN.
##     user -> Tor -> destination
## 
## Sdwdate user:
TUNNEL_FIREWALL_ALLOW_SDWDATE_USER=false
## Whonixcheck:
TUNNEL_FIREWALL_ALLOW_WHONIXCHECK=false
## Tor Browser Downloader
TUNNEL_FIREWALL_ALLOW_TB_UPDATER=false

#####################
## ADVANCED OPTIONS
## Defaults will work for most users. Only change if certain.

## VPN Interfaces
## OpenVPN: use tun0
##
#VPN_INTERFACE=tun0

## Destinations you do not want routed through the VPN.
## Qubes-Whonix Defaults:
##
#    LOCAL_NET="\
#         127.0.0.0-127.0.0.255 \
#         10.137.0.0-10.138.255.255 \
    "

## Non-Qubes-Whonix defaults:
##
#    LOCAL_NET="\
#         127.0.0.0-127.0.0.255 \
#         192.168.0.0-192.168.0.255 \
#         192.168.1.0-192.168.1.255 \
#         10.152.152.0-10.152.152.255 \
#         10.0.2.2-10.0.2.255 \
#   "

Patrick · May 20, 2016, 2:59pm

The name VPN_FIREWALL is in Whonix 13 plain wrong. Limiting. It is a TUNNEL_FIREWALL. Works for any kind of tunneling software in similar ways.

VPN_FIREWALL will stay a synonym for TUNNEL_FIREWALL_ENABLE for legacy reasons.

Ideally yes, but difficult to do for legacy reasons. Changing this could lead to unexpected results for users who upgrade.

Intuitions are different. I was more on the side of users assuming TUNNEL_FIREWALL_ENABLE alone is sufficient. And this way it fails closed.

entr0py · May 20, 2016, 7:49pm

Thanks. Just now learned what sudo -u actually means. All working now.

Updated draft.

This is confusing, especially since instructions explicitly state to set WORKSTATION_FIREWALL=1. Easy fix:

## Setting TUNNEL_FIREWALL_ENABLE=true automatically enables WORKSTATION_FIREWALL=1 and
## overrides any previous setting.

Anticipating issues that users may have with the instructions:

VPN Credentials
The riseup vpn example illustrates password authentication. Many vpn providers issue client keys with 600 permissions. User ‘tunnel’ can’t read.
Best option is probably chown tunnel:tunnel client.key
or for embedded keys: chown tunnel:tunnel client.ovpn

Auto-DNS Configuration
add to /etc/openvpn/openvpn.conf:

script-security 2
up update-dns.sh
down update-dns.sh

in konsole:

sudo touch /etc/resolv.conf.qubes
sudo chown tunnel:tunnel /etc/resolv.conf.anondist
sudo chown tunnel:tunnel /etc/resolv.conf.qubes

Slightly edited version of script circulated on qubes-users (credit: Olivier Médoc), which is itself based on update-resolv-conf.
add to /etc/openvpn/update-dns.sh:

#!/bin/bash

## Modified version of vpn-setup.sh released on qubes-users mailing list. 
## Credit: Olivier Médoc
## Modified to work with Whonix 13 VPN Firewall

## For use with VPNs running under Unprivileged User : tunnel
## Initial setup requires:
##   sudo touch /etc/resolv.conf.qubes
##   sudo chown tunnel:tunnel /etc/resolv.conf
##   sudo chown tunnel:tunnel /etc/resolv.conf.qubes

## To call from openvpn configuration file
##   script-security 2
##   up update-dns.sh
##   down update-dns.sh

## Script will stop working if file permissions are reset/changed
## Repeat setup procedure.

case $script_type in

up)
        # Parses DHCP options from openvpn to update resolv.conf
        # To use set as 'up' and 'down' script in your openvpn *.conf:
        # up /etc/openvpn/update-resolv-conf
        # down /etc/openvpn/update-resolv-conf
        #
        # Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk>
        # and Chris Hanson
        # Licensed under the GNU GPL.  See /usr/share/common-licenses/GPL.
        # 07/2013 colin@daedrum.net Fixed intet name
        # 05/2006 chlauber@bnc.ch
        #
        # Example envs set from openvpn:
        # foreign_option_1='dhcp-option DNS 193.43.27.132'
        # foreign_option_2='dhcp-option DNS 193.43.27.133'
        # foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
        # foreign_option_4='dhcp-option DOMAIN-SEARCH bnc.local'

        # Retrieve DNS related foreign DHCP variable
        for optionname in ${!foreign_option_*} ; do
                option="${!optionname}"
                echo "Parsing DHCP option: $option"
                part1=$(echo "$option" | cut -d " " -f 1)
                if [ "$part1" == "dhcp-option" ] ; then
                        part2=$(echo "$option" | cut -d " " -f 2)
                        part3=$(echo "$option" | cut -d " " -f 3)
                        if [ "$part2" == "DNS" ] ; then
                                IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
                        elif [[ "$part2" == "DOMAIN" || "$part2" == "DOMAIN-SEARCH" ]] ; then
                                IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"
                        fi
                fi
        done

        # Create new resolv.conf content
        if [[ -n "$IF_DNS_SEARCH" || -n "$IF_DNS_NAMESERVERS" ]] ; then
                # Backup resolv.conf
                cp /etc/resolv.conf /etc/resolv.conf.qubes

                # Clear resolv.conf
                echo -n "" > /etc/resolv.conf

                if [ "$IF_DNS_SEARCH" ]; then
                        R="search "
                        for DS in $IF_DNS_SEARCH ; do
                                R="${R} $DS"
                        done
                        echo "$R" >> /etc/resolv.conf
                fi

                for NS in $IF_DNS_NAMESERVERS ; do
                        R="nameserver $NS"
                        echo "$R" >> /etc/resolv.conf
                done

                # Reinit Qubes DNS nat rules
                # Has no effect in Whonix 13. Safe to leave
                /etc/dhclient.d/qubes-setup-dnat-to-ns.sh

        fi
        ;;
down)

        if [ -f /etc/resolv.conf.qubes ] ; then
                # Restore resolv.conf
                cp /etc/resolv.conf.qubes /etc/resolv.conf

                # Reinit Qubes DNS nat rules
                # Has no effect in Whonix 13. Safe to leave
                /etc/dhclient.d/qubes-setup-dnat-to-ns.sh
        fi
        ;;
esac

EDIT: file permssions will be overwritten by updates

Patrick · May 22, 2016, 6:13pm

Still using VPN_FIREWALL two times.

But the guide is using this already, no?
sudo chown -R tunnel:tunnel /etc/openvpn
( Connecting to Tor before a VPN )

The point, advantage of this would be that the user no longer needs to do manual DNS configuration?

That would be nice. In that case we should add that script to the usability-misc package. (And with a different name to the vpn-firewall package [so these can still be co-installed].)

The file name should not be needlessly Qubes specific.

Maybe not. The whole /etc/openvpn/update-dns.sh could get a sudoers exception. Then call the script as root so it can do all of that for the user.

down update-dns.sh

So it will be set back to original DNS settings when the VPN is shut down. Not necessarily bad. Can you please test if with original DNS settings (pointing to Whonix-Gateway)

Please check if that file is executable beforehand.

Which updates?

entr0py · May 22, 2016, 6:19pm

Haven’t uploaded new draft yet! Ok, now I see why git is useful - couple pulls and my head is spinning. I’ll move all my forum spam over there.

All your points noted!

Whonix-13-Workstation VPN-Firewall

su tunnel sudo openvpn openvpn.conf

su tunnel
sudo openvpn openvpn.conf