VPN-Firewall, deafeating shared VPN/Tor server leak bug in Qubes

[Patrick Schleizer]

Work has been done to make VPN-Firewall [1] work with Qubes. (Currently
in the development branch [2].)

It does defeat the 'shared VPN/Tor server leak bug' [1], which to my
knowledge no other Free Software traffic fail closed mechanism for
OpenVPN based VPNs does.

> __problem description__:
>
> If a Tor entry guard is running on the same server (same IP) as the
> VPN server (same IP), and if VPN breaks down, Tor may connect
> directly to the VPN if it happened to choose that Tor relay (same IP)
> as entry guard. This is not that unlikely, because a lot VPN
> providers support VPN port forwarding, use public IPs and people host
> Tor servers behind VPN's.
>
> __(partial solution)__:
>
> (A partial solution for this to set the VPN VM's firewall rules to
> allow connections only to the VPN server. Specifying destination port
> in that firewall rule should help a lot. Some cases will not be
> solved (like VPN running on 443).)
>
> __full solution__:
>
> A full solution is to allow only user tunnel to connect to the open
> internet. All other users not.

VPN-Firewall implements the full solution.

It should currently work in Qubes Standalone AppVMs. Ready to be tested
by advanced users.

Qubes ProxyVM support is not done yet.

Support for Qubes TemplateBasedVMs is not avaialbe yet, due to some
bind-dirs.sh limitations. [5]

The instructions are quite lengthy and difficult. The complexity is
derived from the requirement to run OpenVPN as user "tunnel" so only
that user is allowed to connect to the internet. Everything else blocked.

Feedback welcome. Perhaps you have any ideas how the documentation
and/or implementation could be simplified.

If there is any interest, pre-build Debian packages of VPN-Firewall
could be created and added a (the Whonix) deb repository. That would
simplify the instructions a bit.

Related ticket:
Qubes VPN documentation limitations [4]

Cheers,
Patrick

[1] https://www.whonix.org/wiki/VPN-Firewall
[2] https://github.com/adrelanos/VPN-Firewall/tree/development
[3] https://github.com/adrelanos/vpn-firewall/issues/12
[4] https://github.com/QubesOS/qubes-issues/issues/1941
[5] TemplateBasedVMs: make selected files and folders located in the
root image persistent- review bind-dirs.sh [6]
[6] https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4

[Patrick Schleizer]

VPN-Firewall 1.0 is now capable of serving as a sys-vpn Qubes ProxyVM!

I'd appreciate review!

Leaving all "logistics" aside, the heart is the firewall script:

https://github.com/adrelanos/vpn-firewall/blob/development/usr/share/netfilter-persistent/plugins.d/30_vpn-firewall

Full project:

https://github.com/adrelanos/VPN-Firewall

There are no prebuild Debian packages yet. Available from source only.

Cheers,
Patrick

[Chris Laprise]

On 05/11/2016 09:15 PM, Patrick Schleizer wrote:
> Work has been done to make VPN-Firewall [1] work with Qubes. (Currently
> in the development branch [2].)
>
> It does defeat the 'shared VPN/Tor server leak bug' [1], which to my
> knowledge no other Free Software traffic fail closed mechanism for
> OpenVPN based VPNs does.

Hi Patrick,

Perhaps I have misunderstood the problem description or the nature of
the solution, but I interpret this project as not really being useful to
Qubes users who run vpn in a separate proxy vm. It is for people who
insist on running their vpn client in the same vm as tor, as if they
were still running a traditional Linux or Windows system.

Leak protection for openvpn is very straightforward in a typical Qubes
setup -- by blocking all forwarding to the upstream interface/eth0. I
have not seen anything that can defeat it.

I think even if I wanted tor to somehow keep communicating after the
upstream vpn link went down (for some reason I cannot fathom), I'd be
much safer simply blacklisting my vpn server addresses in tor ...but...
in real life I wouldn't allow tor to keep going under those
circumstances. Blocking all forwarding in the vpn vm is, therefore, a
readily available solution for Qubes.

>
>> __problem description__:
>>
>> If a Tor entry guard is running on the same server (same IP) as the
>> VPN server (same IP), and if VPN breaks down, Tor may connect
>> directly to the VPN if it happened to choose that Tor relay (same IP)
>> as entry guard. This is not that unlikely, because a lot VPN
>> providers support VPN port forwarding, use public IPs and people host
>> Tor servers behind VPN's.
>>
>> __(partial solution)__:
>>
>> (A partial solution for this to set the VPN VM's firewall rules to
>> allow connections only to the VPN server. Specifying destination port
>> in that firewall rule should help a lot. Some cases will not be
>> solved (like VPN running on 443).)
>>
>> __full solution__:
>>
>> A full solution is to allow only user tunnel to connect to the open
>> internet. All other users not.

The concept implicitly relies on security based on Linux
user-permissions. I do not see how this helps Qubes users.

Regards,
Chris

[Chris Laprise]

I have posted a question about this on qubes-issues ticket:

https://github.com/QubesOS/qubes-issues/issues/1941


Chris

[Patrick Schleizer]

Chris Laprise:

>>> A full solution is to allow only user tunnel to connect to the open
>>> internet. All other users not.
>
> The concept implicitly relies on security based on Linux
> user-permissions. I do not see how this helps Qubes users.

Running under user tunnel is not for anti exploitation / security
reasons. It's to sort out tunnel / VPN traffic from other traffic on the
iptables level only.

Cheers,
Patrick

[Patrick Schleizer]

Chris Laprise:

Answered.

Cheers,
Patrick

[Patrick Schleizer]

Chris Laprise:

>
>
> On 05/11/2016 09:15 PM, Patrick Schleizer wrote:
>> Work has been done to make VPN-Firewall [1] work with Qubes. (Currently
>> in the development branch [2].)
>>
>> It does defeat the 'shared VPN/Tor server leak bug' [1], which to my
>> knowledge no other Free Software traffic fail closed mechanism for
>> OpenVPN based VPNs does.
>
> Hi Patrick,
>
> Perhaps I have misunderstood the problem description or the nature of
> the solution, but I interpret this project as not really being useful to
> Qubes users who run vpn in a separate proxy vm. It is for people who
> insist on running their vpn client in the same vm as tor, as if they
> were still running a traditional Linux or Windows system.
>
> Leak protection for openvpn is very straightforward in a typical Qubes
> setup -- by blocking all forwarding to the upstream interface/eth0. I
> have not seen anything that can defeat it.

I somehow missed the /rw/config/qubes-firewall-user-script approach
suggested in:
https://github.com/QubesOS/qubes-issues/issues/1941#issuecomment-217220257

More discussion on that /rw/config/qubes-firewall-user-script approach:
https://github.com/QubesOS/qubes-issues/issues/1941#issuecomment-220818746

Back to answering your VPN-Firewall comments...

I was reading https://www.qubes-os.org/doc/vpn/ before I made
VPN-Firewall work with Qubes. If the
/rw/config/qubes-firewall-user-script approach works out as per
discussion, this indeed somehow limits usefulness of VPN-Firewall for Qubes.

As I understand both approaches currently, when the VPN is run inside
AppVMs, then only VPN-Firewall works. The same should go for NetVMs,
although I have no tested VPN-Firewall with NetVMs yet.

VPN-Firewall Qubes ProxyVM support may or may not have been in vain
indeed. We'll figure that and any differences. I think the advantage by
VPN-Firewall is, that it does enforce all traffic originating from
VPN-Gateway itself is 100% VPN. Including traffic like Fedora phone home
[1], apt [2], ntp, and what I, and everyone else might have overlooked

Cheers,
Patrick

[1] https://github.com/QubesOS/qubes-issues/issues/1814
[2] When updating a TemplateBasedVM if it is undesired to reboot it
after upgrading its TemplateVM.

[Chris Laprise]

I think this approach of dropping or rejecting all forwarding
(forward-blocking?) was intended specifically for a proxy vm dedicated
to openvpn (or similar userspace) service, and no other type of vm. The
idea is you setup a working openvpn configuration and then secure it
with two steps in the same vpn vm:

1. Add forward-blocking with iptables
2. Add a call from openvpn to qubes_setup_dnat_to_ns once a connection
has been made

At that point the vpn vm is complete. It should not be used to setup or
start other applications.

> VPN-Firewall Qubes ProxyVM support may or may not have been in vain
> indeed. We'll figure that and any differences. I think the advantage by
> VPN-Firewall is, that it does enforce all traffic originating from
> VPN-Gateway itself is 100% VPN. Including traffic like Fedora phone home
> [1], apt [2], ntp, and what I, and everyone else might have overlooked

This may be a case where starting with a minimal template is useful (it
is, after all, a type of service vm). However, I have seen nothing
problematic coming from my own vpn vm using a full-fledged desktop template.

It has been a while, but I'll revisit my simple link tests with tcpdump
and then add your whonix-based test to my list to see if any leaks occur
with forward-blocking.

Thanks,
Chris

[Patrick Schleizer]

Chris Laprise:

>> VPN-Firewall Qubes ProxyVM support may or may not have been in vain
>> indeed. We'll figure that and any differences. I think the advantage by
>> VPN-Firewall is, that it does enforce all traffic originating from
>> VPN-Gateway itself is 100% VPN. Including traffic like Fedora phone home
>> [1], apt [2], ntp, and what I, and everyone else might have overlooked
>
> This may be a case where starting with a minimal template is useful (it
> is, after all, a type of service vm). However, I have seen nothing
> problematic coming from my own vpn vm using a full-fledged desktop
> template.
>
> It has been a while, but I'll revisit my simple link tests with tcpdump
> and then add your whonix-based test to my list to see if any leaks occur
> with forward-blocking.

Cool. While you're at it, please consider to have a look at
https://www.whonix.org/wiki/Dev/Leak_Tests if it has any other useful
leak testing inspiration that also applies to VPNs.

Cheers,
Patrick

[Unman]

I'm a bit late in on this - Chris is right in his approach.
I posted to the users list about a year ago with an iptables
implementation that covers both putative problems, in relation to openvpn.

<quote>
Use the "redirect-gateway def1" directive in the client.conf file. Some
people try to push this from the server conf, but with variable success.
Using this directive will rewrite the default route while the tunnel is
up and restore the original when the tunnel is down.

By default the nat table will redirect dns traffic up the qubes VM
chain-
you want to change this behaviour to route it down the tunnel. The
easiest way to do this is to add a rule to
/rw/config/qubes-firewall-user-script,
like this:
/sbin/iptables -t nat -I PR-QBS -p udp --dport 53 -j DNAT --to x.x.x.x:53
where x.x.x.x is the IP address of a dns server used by the SERVER end
of the vpn.

Now change the firewall settings for the new proxyVM to only allow
traffic to the openvpn server - in VM manager, deselect ICMP and DNS
traffic, and DENY access except to the server, specifying IP, protocol
and port.

</quote>

This is pretty standard stuff.
I'm posting in more detail to the issues list.

unman

[Chris Laprise]

Some notes about a VPN firewall solution...


Objectives:
* Prevent all communication between downstream vms and upstream clearnet
(eth0) when the vpn client fails or the link goes down.
* Implement vpn link as a dedicated vm, transparent to downstream vms.
* Remain compatible with conventional server names for the vpn server.
* Prevent accidental communication from non-vpn programs in vpn vm to
anywhere.
* Prevent attempted communication with non-vpn programs in the vpn vm
(appears already enforced by Qubes firewall).


Roles:
* The vpn vm is generally trusted. It is assumed its programs won't try
to impersonate openvpn (send data via port 1194), for example.
* Everything outside the vpn vm and vpn server is essentially untrusted
(from the vpn client's point of view): This means the sys-net, local
router, ISP and downstream vms are potential threats. (This doesn't
affect the users POV of whether individual appvms are trusted.)
* Everything that is downstream from vpn vm communicates through the vpn
tunnel only.
* The purpose of the programs in the vpn vm is to support the creation
of the vpn link. Their communication domain is either null or clearnet
only; they should not send packets through the vpn tunnel and
potentially published.


Proposed rules for /rw/config/qubes-firewall-user-script:
---
-I FORWARD 1 -o eth0 -j DROP
-I FORWARD 2 -i eth0 -j DROP
-P OUTPUT DROP
-F OUTPUT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p udp -o eth0 --dport 1194 -j ACCEPT
-A OUTPUT -p tcp -o eth0 --dport 1194 -j ACCEPT
-A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
---

This works well with the '/redirect-gateway def1/' openvpn directive,
which was the default for my vpn service.

I left out the "OUTPUT -o tun0 -j ACCEPT" rule as this allows local (vpn
vm) programs to communicate over the tunnel.

One thing still bothers me, the ACCEPT for any icmp INPUT (from Qubes
firewall default). I think this should be changed to accept icmp only
from eth0.

Chris

[Ivan]

Hi,

On 05/27/2016 04:00 PM, Chris Laprise wrote:
> Some notes about a VPN firewall solution...
>
>
> Objectives:
> * Prevent all communication between downstream vms and upstream clearnet
> (eth0) when the vpn client fails or the link goes down.
> * Implement vpn link as a dedicated vm, transparent to downstream vms.
> * Remain compatible with conventional server names for the vpn server.
> * Prevent accidental communication from non-vpn programs in vpn vm to
> anywhere.
> * Prevent attempted communication with non-vpn programs in the vpn vm
> (appears already enforced by Qubes firewall).
>
>
> Roles:
> * The vpn vm is generally trusted. It is assumed its programs won't try
> to impersonate openvpn (send data via port 1194), for example.

If that's a concern, you may restrict sending data to port 1194 only by
the openvpn user, like so:

-A OUTPUT -p [...] -o eth0 --dport 1194 -m owner --uid-owner openvpn -j
ACCEPT

The same can be done for the owner of programs doing domain name resolution.

This is of course fine if the reason a program would "impersonate"
openvpn is because of a developer's mistake or a weird setup. If those
programs are malicious those rules won't help much (privilege
escalation, and game over for that vm).

Cheers,
Ivan

[Chris Laprise]

I surmise that a weird setup or mistake could as easily run other
programs as the openvpn user (and for many network functions, the error
is far less detectable). The difference is that various distros may or
may not set this up as default, making this aspect of setup for Qubes
difficult to script and document. Scripting from within openvpn is also
harder with the user sandbox in place, and it gets us no added security
(the vpn password/key is the only thing of value in the vm).

In this Qubes context, the port number identifies the program about as
accurately as a username, and its infinitely simpler and more likely to
work. That's important, since trying to protect against occasional
mistyped commands in the vpn vm is not the point of all this... IMHO its
a tertiary concern. The main issue is that no data be forwarded between
vif+ and eth0.

OTOH, if you already have a user-sandboxed vpn working in a proxy vm
then adding the owner rule just takes one line.

Chris

[Chris Laprise]

On 05/27/2016 09:41 AM, Ivan wrote:

I've found its very easy to assign a group to processes, using a systemd
directive like 'Group=' or a command 'sg'. Only preparation is 'groupadd
-r groupname' with no added dirs, file permissions or other user-related
baggage. And the client keeps its root user status which means fewer
obstacles with scripting. The iptables owner module happily filters
groups with the --gid-owner parameter. :)

-A OUTPUT -p [...] -o eth0 -m owner --gid-owner vpn -j ACCEPT

I think this method should at least be mentioned as an alternative to
filtering by --dport number. With the above rule, any regular vpn client
can be assigned 'vpn' group so the firewall script doesn't need to be
edited to fit openvpn, bitmask, etc.

Chris

[sowowsuc...@onenetbeyond.org]

Hi,

What about taking a step against the js audio fingerprint issue in
Qubes? At this moment it beats all protection as this can fingerprint on
hardware level, nearly on any OS.

Ref.: https://audiofingerprint.openwpm.com/

Example: visit twitter on your laptop through open internet, then visit
twitter again without logging in through the same laptop, but Tails.
Result is that twitter identify you based on the js audio fingerprint
and knows it's the same computer.

Note: if you want to test the fingerprinting throguh different virtual
machines/tails/tor browser/etc, you better get the code from github and
run for yourself.

https://github.com/Valve/fingerprintjs2

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-30 03:13, sowowsuc...@onenetbeyond.org wrote:
> Hi,
>
> What about taking a step against the js audio fingerprint issue in
> Qubes? At this moment it beats all protection as this can
> fingerprint on hardware level, nearly on any OS.
>
> Ref.: https://audiofingerprint.openwpm.com/
>
> Example: visit twitter on your laptop through open internet, then
> visit twitter again without logging in through the same laptop, but
> Tails. Result is that twitter identify you based on the js audio
> fingerprint and knows it's the same computer.
>

Simply using two different browsers (Google Chrome and Firefox) in the
same VM resulted in different fingerprints for me, so "knows it's the
same computer" might be a stretch.

> Note: if you want to test the fingerprinting throguh different
> virtual machines/tails/tor browser/etc, you better get the code
> from github and run for yourself.
>
> https://github.com/Valve/fingerprintjs2
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXTBuEAAoJENtN07w5UDAwJ58QALLn/85ai8npiY9HOfYFWKHp
XlzNPJmUJ57nAcGhVff//QfjpTu9ZZNh3RrLQfLcQY22WNWbEJQm77mlO/MCSZN4
QkKue962Io78Gfg8UyhULo9FX0cde5RakTiHQBGZUsvtDgLPMEp0KmEiSOa1QUBi
a4r+ncyMe3q9bl7tOm57dIaOBoRm5OoMJJe6dFAkLqQ1Cw3lJycqb/RdWDQ7qYzh
alnN6EqLTE/+hWrnEz11pyIS4hPnyMKysHJvhJzAkUmYvCpIOkSMuFUqPBpVVPJZ
hoeGVtfeIEEtcqM5OOvgDv0hAn18bAenjvM8jFEeY80IloBGfWGJkMHaz4Bi09f+
d2VwfnQhonZzrt4elzcgU0tDGTC+xWJjrfYUGvkvqN5jEP84qyzBloP52c1sT/fc
sFhVOi5K/TuM2dgdoIY9d44zCm/MeVIKXt6LPS3d/WrfbfSWhaXptD/vyhZk4+I8
Y2zww8wKRbo1wyDEv7Mk0mP3yQ4l95qI6iJPnvyLW4P/HX8pvGihRblcp92lJ6SA
RGZT/t8uN2c/AD54DyTVAeq4jrnpeYkmYOsXff8SE4iEkFj84JHO59WSS5Gtvfbn
cn9mM0PEGMGrF6unhgxU45Yp3hxPFzxoZs6Y/upSJz0PcKfrJvpugXDa1eyPtPTd
YsiepoUpQTCmnHewlGT3
=QmEA
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, May 30, 2016 at 03:52:56AM -0700, Andrew David Wong wrote:
> On 2016-05-30 03:13, sowowsuc...@onenetbeyond.org wrote:
> > Hi,
> >
> > What about taking a step against the js audio fingerprint issue in
> > Qubes? At this moment it beats all protection as this can
> > fingerprint on hardware level, nearly on any OS.
> >
> > Ref.: https://audiofingerprint.openwpm.com/
> >
> > Example: visit twitter on your laptop through open internet, then
> > visit twitter again without logging in through the same laptop, but
> > Tails. Result is that twitter identify you based on the js audio
> > fingerprint and knows it's the same computer.
> >
>
> Simply using two different browsers (Google Chrome and Firefox) in the
> same VM resulted in different fingerprints for me, so "knows it's the
> same computer" might be a stretch.

On the other hand, using Firefox on different Qubes instances
(even different Qubes versions: 3.0 vs 3.1), I've got the same
fingerprint.

This is not surprising, as VM have no access to real hardware, only to
emulated sound device (more precisely: pulseaudio sink) - which is the
same for all Qubes users.

> > Note: if you want to test the fingerprinting throguh different
> > virtual machines/tails/tor browser/etc, you better get the code
> > from github and run for yourself.
> >
> > https://github.com/Valve/fingerprintjs2
> >
>

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXTB4vAAoJENuP0xzK19cszrQIAI0I5zX8f51YUigRQFbqTEna
GbAXKAoHxU3Jn9X6dq6/4F6gValgmrxQwhb0mYNJ1Nr81u3m/Z1QxLHqih6o5ftY
KVO3B9LA2ELEM11fg9lclmMWwDrZ1ZxNHVpCsFI+5WhnuqcPVXrMtMo60rVubOSD
cAp/3sr5BjJHLdRLimuDySCsCdshghFybUqcFWA6HpLeGUTT0n/nqXdbcAGWbMSL
S0mo38haTJPKBheNMGGSGS3E/SxNcRIMhWtNJubMd76zQTshDKywm11B5qvXqWVf
4dbs0ln7N52FnU1Nq111WO3p6/J1Okdi0CrEoy+b3C2B2wmMHPCVjlMS6vkTvQE=
=yyV9
-----END PGP SIGNATURE-----

[Chris Laprise]

Here's a revision of the firewall script:


---
########################################################################
##
## qubes-firewall-user-script for use with a VPN client such as openvpn.
##
##

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

## Stop all leaks between downstream (AppVMs) and upstream (Internet):
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

## Prevent accidental communications from within VPN VM;
## The gid-owner rule requires the VPN client be run with group ID 'qvpn'
## to allow outbound traffic from the client. It can be replaced by
un-commenting
## the two --dport 1194 rules (if you are not using the group ID).
iptables -F OUTPUT
iptables -A OUTPUT -o lo -j ACCEPT
#iptables -A OUTPUT -p udp -o eth0 --dport 1194 -m state --state
NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -p tcp -o eth0 --dport 1194 -m state --state
NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p all -o eth0 -m owner --gid-owner qvpn -m state
NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 --dport 53 -m state NEW,ESTABLISHED -j
ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport 53 -m state NEW,ESTABLISHED -j
ACCEPT

## Block INPUT from downstream and the tunnel:
iptables -I INPUT -i vif+ -j DROP
iptables -I INPUT -i tun0 -j DROP
## Disable icmp packets (re-enable for testing and debugging):
if iptables -C INPUT -p icmp -j ACCEPT
then iptables -D INPUT -p icmp -j ACCEPT
fi

## Block all IPv6 traffic (generally unsupported in Qubes):
ip6tables -P OUTPUT DROP
ip6tables -F OUTPUT
ip6tables -P FORWARD DROP
ip6tables -F FORWARD
ip6tables -P INPUT DROP
ip6tables -F INPUT
---


Of course, this builds on the rules already set by Qubes 3.1 firewall.

Note: There are no hard-coded IPs and the OUTPUT controls VPN traffic by
group ID. So if your VPN provider has dozens of IPs randomly-assigned
via DNS or uses a client other than openvpn then no editing of the
firewall script should be necessary.

Group ID can be easily assigned to VPN client with /rw/config/rc.local
like this:
groupadd -r qvpn
sg qvpn -c 'openvpn --cd /rw/config/openvpn/ --config
openvpn-client.ovpn \
--daemon --writepid /var/run/openvpn/openvpn-client.pid'

...or you can add a "Group=qvpn" line to the Service section of your
systemd openvpn.service file.

Also, local traffic to and from tun0 and vif+ is disallowed, as well as
incoming icmp packets.

I'm going to follow-up with a suggested openvpn "up" script that will
take care of the dns-dnat rules in chain PR-QBS. The user can opt to
enter their vpn dns addresses or let dhcp supply them automatically.

I'll also resume testing for leaks using this configuration, including
the Whonix tests Patrick referenced.

Chris

[Chris Laprise]

On 05/30/2016 08:03 PM, Chris Laprise wrote:
> Here's a revision of the firewall script:
>
> ---

> I'm going to follow-up with a suggested openvpn "up" script that will
> take care of the dns-dnat rules in chain PR-QBS. The user can opt to
> enter their vpn dns addresses or let dhcp supply them automatically.
>

Here is the openvpn 'up' script and other files to go with the VPN firewall:

https://github.com/ttasket/Qubes-vpn-support/blob/master/rw/config/openvpn/qubes-vpn-handler.sh

Chris

[Patrick Schleizer]

Chris Laprise:

Please change the subject line as this is unrelated to 'VPN-Firewall,
defeating shared VPN/Tor server leak bug in Qubes'.