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
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.
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âŠ
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:
#########################################
## 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 \
# "
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
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.