ANN: Leakproof Qubes VPN

[Manuel Amador (Rudd-O)]

It gives me great pleasure to release the first iteration of the
leakproof Qubes VPN.

https://github.com/Rudd-O/qubes-vpn

This package allows you to set up a leakproof OpenVPN VM on your Qubes
OS system. All VMs attached to the VPN VM are automatically and
transparently routed through the VPN. DNS requests do not hit the NetVM
they get routed through the VPN instead.

Users and developers welcome to contribute to the project in any way you
can!

--
Rudd-O
http://rudd-o.com/

[7v5w7go9ub0o]

(Nice documentation!)

TU, Sir!

[Marek Marczykowski-Górecki]

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

Nice! I've briefly reviewed it and it looks good :)

I think it would be good to have it in standard repository. See
"Packaging 3rd-party software" message on qubes-devel I just sent.

- --
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

iQEcBAEBCAAGBQJX/rbOAAoJENuP0xzK19csrj0H+wXOEA0dvApo1TCQynJ1LImc
+IPUu3cm8PrWa86+RQ5UsL7YKO+vhAjB2eW9KzCObKimWwd3UhGpXHQdlc4keEdy
d8SLr7ipZm4Yl9L3ap/z/TMzf/tO9gGpNfNAloH8BJrlCh7Lf8+xhLqQ7ryFlplZ
cxg+cXxpanxQbqc4ty395sfAznvLB040maxgJ9HX5zMi1hKBtdbfNcdGaHEsy3RI
MdCvNr7JETj49InUuLbgSXhUZFyyZccN3EnZcSRhnRZ+VaGSTAEuFrczv7SA8GnF
qYY1Te2pziMVOJwZA4ccm4MVXV8utRCjBygJe8MWBEDuAFZZF4W4myjP1sLAW8Q=
=kxUp
-----END PGP SIGNATURE-----

[Chris Laprise]

On 10/12/2016 06:18 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wed, Oct 12, 2016 at 09:35:45PM +0000, Manuel Amador (Rudd-O) wrote:
>> It gives me great pleasure to release the first iteration of the
>> leakproof Qubes VPN.
>>
>> https://github.com/Rudd-O/qubes-vpn
>>
>> This package allows you to set up a leakproof OpenVPN VM on your Qubes
>> OS system. All VMs attached to the VPN VM are automatically and
>> transparently routed through the VPN. DNS requests do not hit the NetVM
>> they get routed through the VPN instead.
>>
>> Users and developers welcome to contribute to the project in any way you
>> can!
> Nice! I've briefly reviewed it and it looks good :)
>
> I think it would be good to have it in standard repository. See
> "Packaging 3rd-party software" message on qubes-devel I just sent.
>
> - --

Although I like a packaged solution, I think anyone should be wary of
manipulating routing tables to create a "leak-proof" environment.
Hyperbole aside, VPN clients frequently change routing tables directly.

The firewall is more reliable for this application. It makes sense to
package the existing solution since we know its relatively client
agnostic and more importantly fills Patrick's requirements for Tor
isolation.

Chris

[Chris Laprise]

Here is a rundown of initial concerns...

* Routing tables should not be manipulated when VPN clients will surely
do this as well

* Unknown side-effects with different VPN topologies (i.e. atypical
routing commands pushed down to the VPN client)

* Interdependent packet marking, detection and routing rules are
needlessly complex

* Hardly a model for 'fail closed': Instead of being steady-state,
blocking is dependent on state transitions in fw/routes (even worse,
ones that are initiated by OpenVPN events). Blocking should not require
active measures initiated by client software.

* Specific to Fedora template and hard-coded for OpenVPN

* Not /rw based; Adds more services to template

* Not tested with Whonix/Tor

* Uncommented code

* A full throttle busy-wait loop in 'qubes-vpn-forwarding.in'

* Marketing hyperbole like "leak-proof" should be replaced with terms
like "anti-leak"

* Critique of existing solution stops at 'No packaging'[1]; Oddly,
nothing pertaining to anti-leak abilities

--

So what I see thus far is that the concerns and requirements expressed
in issue #1941 [2] are being ignored here.

The asked-for solution was to be contained in documentation and have
instructional value for the reader, which is why explanations from the
preceding version were retained as script comments. But under the new
circumstances I see nothing preventing the existing VPN doc solution
from being incorporated into Qubes.

Chris


1.
https://groups.google.com/d/msgid/qubes-users/6311d51d-daaa-e4de-e838-7fa319ba0b01%40rudd-o.com

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

[Manuel Amador (Rudd-O)]

Thank you. Major improvement just got pushed. It has notifications
now, as well
as running the openvpn daemonn as a regular user, and automatic restarts
when the connection falis.

>
> TU, Sir!
>

You're welcome!

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 10/12/2016 10:18 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 12, 2016 at 09:35:45PM +0000, Manuel Amador (Rudd-O) wrote:
> > It gives me great pleasure to release the first iteration of the
> > leakproof Qubes VPN.
>
> > https://github.com/Rudd-O/qubes-vpn
>
> > This package allows you to set up a leakproof OpenVPN VM on your Qubes
> > OS system. All VMs attached to the VPN VM are automatically and
> > transparently routed through the VPN. DNS requests do not hit the NetVM
> > they get routed through the VPN instead.
>
> > Users and developers welcome to contribute to the project in any way you
> > can!
>
> Nice! I've briefly reviewed it and it looks good :)
>
> I think it would be good to have it in standard repository. See
> "Packaging 3rd-party software" message on qubes-devel I just sent.
>

Thank you. You may want to review the new update I just made. Gained
new features and improved security.
--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 10/13/2016 12:00 AM, Chris Laprise wrote:
> On 10/12/2016 06:18 PM, Marek Marczykowski-Górecki wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On Wed, Oct 12, 2016 at 09:35:45PM +0000, Manuel Amador (Rudd-O) wrote:
>>> It gives me great pleasure to release the first iteration of the
>>> leakproof Qubes VPN.
>>>
>>> https://github.com/Rudd-O/qubes-vpn
>>>
>>> This package allows you to set up a leakproof OpenVPN VM on your Qubes
>>> OS system. All VMs attached to the VPN VM are automatically and
>>> transparently routed through the VPN. DNS requests do not hit the NetVM
>>> they get routed through the VPN instead.
>>>
>>> Users and developers welcome to contribute to the project in any way
>>> you
>>> can!
>> Nice! I've briefly reviewed it and it looks good :)
>>
>> I think it would be good to have it in standard repository. See
>> "Packaging 3rd-party software" message on qubes-devel I just sent.
>>
>> - --
>
> Although I like a packaged solution, I think anyone should be wary of
> manipulating routing tables to create a "leak-proof" environment.
> Hyperbole aside, VPN clients frequently change routing tables directly.

My program directs openvpn not to change any routing tables and, in
fact, tells openvpn to run in unprivileged mode where openvpn cannot
change any routing tables itself.

>
> The firewall is more reliable for this application. It makes sense to
> package the existing solution since we know its relatively client
> agnostic and more importantly fills Patrick's requirements for Tor
> isolation.

Though I do not understand what you mean by "the firewall is more
reliable", as my program runs under a ProxyVM fine, that solution should
be packaged too, perhaps under a different name.


--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 10/13/2016 03:13 AM, Chris Laprise wrote:
> Here is a rundown of initial concerns...
>
> * Routing tables should not be manipulated when VPN clients will
> surely do this as well

The program prohibits OpenVPN from manipulating routing tables.

>
> * Unknown side-effects with different VPN topologies (i.e. atypical
> routing commands pushed down to the VPN client)

Almost no routing instructions are obeyed. Those which are obeyed, are
applied to routing table 78, which prevents malicious server
manipulation of ProxyVM routing tables.

>
> * Interdependent packet marking, detection and routing rules are
> needlessly complex

FWMARK was the only way to get blackholing to work reliably without
interference from the Qubes OS firewalling system.

>
> * Hardly a model for 'fail closed': Instead of being steady-state,
> blocking is dependent on state transitions in fw/routes (even worse,
> ones that are initiated by OpenVPN events). Blocking should not
> require active measures initiated by client software.

Check the code again. Blocking happens way before VPN and Qubes
Firewall starts. If there's a failure in the VPN, even if the
re-blackholing fails, no traffic from the VMs will be routed, simply
because everything is FWMARKed to go to routing table 78, which is dead
by the time VPN fails.

>
> * Specific to Fedora template and hard-coded for OpenVPN

Yes, this is specific to Fedora and hard-coded for OpenVPN. OpenVPN is
the standard these days. I welcome pull requests to enhance it for
other VPN solutions.

>
> * Not /rw based; Adds more services to template

Partially true. Config goes in /rw as it should. Services are optional
and need to be specifically enabled.

Frankly, much better than an instruction manual, or putting all of the
stuff in /rw/config/firewall stuff, because it being a package, it can
be updated regularly, given a repo containing the packages.

>
> * Not tested with Whonix/Tor

True. Then again, Whonix has its own "VPN" solution called TOR.

>
> * Uncommented code
>

There are a few comments now. Surely not enough to satisfy your
standards, but I welcome pull requests.

> * A full throttle busy-wait loop in 'qubes-vpn-forwarding.in'

Please point out the line of code where that happens. I don't think I
have done that.

>
> * Marketing hyperbole like "leak-proof" should be replaced with terms
> like "anti-leak"

If you think it's possible to have this VPN leak, then prove you can
cause a leak, and — if you succeed — I will plug the leak.

>
> * Critique of existing solution stops at 'No packaging'[1]; Oddly,
> nothing pertaining to anti-leak abili

Sorry, gotta go to bed. I have a suggestion: I think we will
collaborate better w.r.t bringing a standardized leak-proof solution to
Qubes, if we approach the issue in a non-confrontational and
collaborative way. I'm happy to have criticisms because they tend to
improve the software, but I fail to see valid criticisms here, which
makes me feel like you jumped to critiquing without trying what you were
critiquing. Let's get some more solid criticisms based on facts and not
on opinions or hunches.

--
Rudd-O
http://rudd-o.com/

[Chris Laprise]

On 10/13/2016 01:08 AM, Manuel Amador (Rudd-O) wrote:
> On 10/13/2016 03:13 AM, Chris Laprise wrote:
>> Here is a rundown of initial concerns...
>>
>> * Routing tables should not be manipulated when VPN clients will
>> surely do this as well
> The program prohibits OpenVPN from manipulating routing tables.

So this is dependent on OpenVPN's features, again.

And is forcing your routing schema on an unknown VPN topology wise?

>
>> * Unknown side-effects with different VPN topologies (i.e. atypical
>> routing commands pushed down to the VPN client)
> Almost no routing instructions are obeyed. Those which are obeyed, are
> applied to routing table 78, which prevents malicious server
> manipulation of ProxyVM routing tables.

Routing tables should be irrelevant to whether non-VPN traffic is
blocked by a proxyVM. A VPN server should be able to push down whichever
routes it sees fit, without any risk of leakage even if those rules are
malicious... or simply a configuration you can't anticipate.

Making the solution dependent on routing tables just makes the security
*and* the operation more precarious.

>
>> * Interdependent packet marking, detection and routing rules are
>> needlessly complex
> FWMARK was the only way to get blackholing to work reliably without
> interference from the Qubes OS firewalling system.

So you added complexity where simply blocking all forwarding to/from
eth0 would have sufficed.

>> * Hardly a model for 'fail closed': Instead of being steady-state,
>> blocking is dependent on state transitions in fw/routes (even worse,
>> ones that are initiated by OpenVPN events). Blocking should not
>> require active measures initiated by client software.
> Check the code again. Blocking happens way before VPN and Qubes
> Firewall starts. If there's a failure in the VPN, even if the
> re-blackholing fails, no traffic from the VMs will be routed, simply
> because everything is FWMARKed to go to routing table 78, which is dead
> by the time VPN fails.

I can see the code where 'up' and 'down' are reconfiguring both iptables
and routing tables. That is using OpenVPN events to shift between
states, one of which is the so-called "blackhole" mode... which looks
more like the makings for a zombie process.

OTOH, its possible that Qubes proxyVMs might leak packets before Qubes
firewall starts, as you claim. That has implications for *most* use
cases involving proxyVMs. Did you think to test that and submit an issue?

>
>> * Specific to Fedora template and hard-coded for OpenVPN
> Yes, this is specific to Fedora and hard-coded for OpenVPN. OpenVPN is
> the standard

...is presumptuous.

>> * Not /rw based; Adds more services to template
> Partially true. Config goes in /rw as it should. Services are optional
> and need to be specifically enabled.

They need to be enabled, but they are still there. That does negatively
affect security from the Qubes perspective; Why should we have even more
privileged code laying around in multiple VMs just because one of them
uses a VPN?

> Frankly, much better than an instruction manual, or putting all of the
> stuff in /rw/config/firewall stuff, because it being a package, it can
> be updated regularly, given a repo containing the packages.

Yes, you were suggesting that people incorporate your repo, while
pretending the Qubes-approved solution didn't exist.

>> * Not tested with Whonix/Tor
> True. Then again, Whonix has its own "VPN" solution called TOR.

Oh, OK.

>> * Uncommented code
>>
> There are a few comments now. Surely not enough to satisfy your
> standards, but I welcome pull requests.
>
>> * A full throttle busy-wait loop in 'qubes-vpn-forwarding.in'
> Please point out the line of code where that happens. I don't think I
> have done that.

Its the /only/ loop in that script ...and boy is it ugly. :)

>
>> * Marketing hyperbole like "leak-proof" should be replaced with terms
>> like "anti-leak"
> If you think it's possible to have this VPN leak, then prove you can
> cause a leak, and — if you succeed — I will plug the leak.

Why move the goalposts? You explain why the existing solution, which is
very unlike your complex set of rules, is insufficient *other* than not
being packaged.

>
>> * Critique of existing solution stops at 'No packaging'[1]; Oddly,
>> nothing pertaining to anti-leak abili
> Sorry, gotta go to bed. I have a suggestion: I think we will
> collaborate better w.r.t bringing a standardized leak-proof solution to
> Qubes, if we approach the issue in a non-confrontational and
> collaborative way. I'm happy to have criticisms because they tend to
> improve the software, but I fail to see valid criticisms here, which
> makes me feel like you jumped to critiquing without trying what you were
> critiquing. Let's get some more solid criticisms based on facts and not
> on opinions or hunches.

Lets "collaborate"? How disingenuous...

We already have a Qubes-approved solution that is considered secure. You
did not seek to package, improve, criticize or even /acknowledge/ it
before you started suggesting people integrate your repo into their
templates! That, quite frankly, is suspicious behavior reminiscent of
the "bum rush" and whether its inadvertent or not isn't my concern.

If this seems uncouth to you, let me provide a reminder that this is a
project where Joanna has advised we should distrust even ITL staff. Its
advice that smartly sets the parameters of skepticism for just this sort
of occasion.

Chris

[Manuel Amador (Rudd-O)]

On 10/13/2016 02:14 PM, Chris Laprise wrote:
>
> So this is dependent on OpenVPN's features, again.

Yes, I make no secret of the fact that my software depends on OpenVPN.
I accept contributions to make it work with other VPN solutions.

>
> And is forcing your routing schema on an unknown VPN topology wise?

I don't know what you mean by "forcing" or "my schema" or "wise". I
know that my program creates a private routing table for the VPN, so the
system routing table is not affected. This is less unsafe than, for
example, what NetworkManager VPN does — which alters your system routing
table.

>
> Routing tables should be irrelevant to whether non-VPN traffic is
> blocked by a proxyVM.

This is a nice opinion, and you are entitled to it. However, it turns
out that using a blackhole routing rule is quite effective at blocking
any and all non-VPN traffic.

> A VPN server should be able to push down whichever routes it sees fit,
> without any risk of leakage even if those rules are malicious... or
> simply a configuration you can't anticipate.

Oh, that's true. And Qubes-VPN supports that. Because it uses a
separate routing table, the system's operation is not affected even if
the VPN server sends malicious or nonsensical routes.

>
> Making the solution dependent on routing tables just makes the
> security *and* the operation more precarious.

While Qubes VPN does not depend solely on routing tables, I would like
to see you prove these allegations. This allegation of yours sounds
like something you can prove by reasoning or by example. Why not do it?

Let's also get one thing out of the way here, because what you're saying
here is borderline FUD.

ALL VPN solutions depend upon routing tables.

There are no VPNs that do not use routing tables on the client to direct
traffic.

Qubes VPN merely uses a *separate* routing table, not the system routing
table (table #0).

So when you say that "making the solution dependent on routing tables"
is somehow bad, you're attacking *all* VPN software.

>
>>
>>> * Interdependent packet marking, detection and routing rules are
>>> needlessly complex
>> FWMARK was the only way to get blackholing to work reliably without
>> interference from the Qubes OS firewalling system.
>
> So you added complexity where simply blocking all forwarding to/from
> eth0 would have sufficed.

Not really. I implemented the simplest and least-invasive solution I
could think of. It's four directives:

1. Instruct the routing engine to route all packets from downstream VMs
to use table 78. This happens very early during boot, right after the
Qubes OS default firewall rules are loaded, and so it happens that VMs
cannot leak.
2. Tell table 78 to route all traffic to the VPN if the VPN interface is
active, and to blackhole all traffic if the VPN interface goes down.
This is actually quite cool, because there's no need to clean up
anything if the VPN fails — the routes disappear when the TUN/TAP device
goes away, leaving the blackhole route active.
3. Add two firewall rules directing all DNS requests from downstream VMs
to the DNS servers of the VPN.

I think, in my humble opinion, that this compares /quite favorably/ with
(the doc) asking the user to write several scripts, all of which make
much more invasive iptables modifications, while still allowing the VPN
server to muck with the system routing table, a practice which under
some circumstances could cause the ProxyVM itself to use the wrong DNS
servers, or to fail to reconnect to the VPN.

Additionally, I see that some of the tables that the doc's scripts
modify are actually tables that the Qubes firewall may revert to their
original state, so it's quite easy for a firewall config change to blow
those rules up, leaving the user with a leaky VPN. Granted, the
firewall config change will only last about a half a second, because the
user firewall script will be invoked afterwards, but during that
half-second, traffic can leak via the eth0 route. OOPS!

>
>>> * Hardly a model for 'fail closed':

I forgot to mention that the software I wrote is 100% fail-closed. If
the VPN fails, traffic from VMs will always be blackholed. There's no
way that this rule can be altered by VMs or the VPN itself.

>>> Instead of being steady-state,

The steady fail-safe state is established very early on boot by the
qubes-vpn-forwarding.service unit file. That steady fail-safe state —
represented by the blackhole rule in table 78 and the firewall rule
routing downstream traffic to table 78 — is never removed during any
state transition.

>>> blocking is dependent on state transitions in fw/routes (even worse,
>>> ones that are initiated by OpenVPN events). Blocking should not
>>> require active measures initiated by client software.
>> Check the code again. Blocking happens way before VPN and Qubes
>> Firewall starts. If there's a failure in the VPN, even if the
>> re-blackholing fails, no traffic from the VMs will be routed, simply
>> because everything is FWMARKed to go to routing table 78, which is dead
>> by the time VPN fails.
>
> I can see the code where 'up' and 'down' are reconfiguring both
> iptables and routing tables.

You can see it, but you don't seem to have understood it. Maybe it is
my fault for not documenting it, but I will fix that now.

* The activation of qubes-iptables (right when the firewall is initially
set up) triggers the activation of "qubes-vpn-forwarding on". This sets
up the steady state (routing 100% blackholed).
* OpenVPN "up" calls "qubes-vpn-forwarding setuprouting". This adds the
routes that OpenVPN wants to table 78. Then, OpenVPN "up" directs the
firewall to route AppVM DNS requests to the VPN DNS servers. Before
"up", all AppVM packets, including DNS, get blackholed. After "up",
they are NATted to the VPN.
* OpenVPN "down" calls "qubes-vpn-forwarding blackhole". Blackhole
simply removes all table 78 routes that aren't the blackhole route.
This ends any routing on table 78, and therefore traffic from all
AppVMs. It /is worth noting/ that, even if these routing rules were to
not be deleted — they do, automatically, when the TUN/TAP device goes
down — no routing would happen anyway.
* "qubes-vpn-forwarding off" is never called except when qubes-iptables
service is reloaded on the ProxyVM (not done unless you do it by hand).

(BAM, just pushed the docs to the README file in the repo.
https://github.com/Rudd-O/qubes-vpn#theory-of-operation )

> That is using OpenVPN events to shift between states,one of which is
> the so-called "blackhole" mode...

Does the word "blackhole" sound scary to you? It simply means "delete
all routing rules of the VPN, leaving the already-existing null route in
place". This is hardly a difficult concept to grasp or to insinuate
negatively about.

> which looks more like the makings for a zombie process.

I don't know what you meant by this in this context.

>
> OTOH, its possible that Qubes proxyVMs might leak packets before Qubes
> firewall starts, as you claim. That has implications for *most* use
> cases involving proxyVMs. Did you think to test that and submit an issue?

Only in VPN case. I wrote the fix for it :-). We're discussing it.

>
>>
>>> * Specific to Fedora template and hard-coded for OpenVPN
>> Yes, this is specific to Fedora and hard-coded for OpenVPN. OpenVPN is
>> the standard
> ...is presumptuous.

Yes, I am presuming that the people using the software I wrote will use
OpenVPN.

This is, of course, by no means the end of the story, of course. I will
gladly add support for other VPN software, and perhaps even
NetworkManager, to Qubes VPN. I just need to find users who are
interested in getting those new features, and possibly help with them as
well.

Of course, once we have support for more than one VPN, it would be
*great* if my software could be upstreamed. I'll work on getting there
when time comes due. Not yet.

>
>>> * Not /rw based; Adds more services to template
>> Partially true. Config goes in /rw as it should. Services are optional
>> and need to be specifically enabled.
>
> They need to be enabled, but they are still there. That does
> negatively affect security from the Qubes perspective;

Are we doing a bit of security by superstition here? If the program is
installed, but it never runs, because the user has not enabled the Qubes
service or configured the program, how exactly is security "negatively
affected"? Are the evil demons going to spawn from the evil program I
wrote, just because it's present? Sorry, this sounds a bit too
Poltergeist or Pet Semetery for me.

> Why should we have even more privileged code laying around in multiple
> VMs just because one of them uses a VPN?

My program does not ship any privileged code.

I repeat what I said earlier: installing my program does not run
anything that affects VM state, unless the user has expressly enabled
it. And even then, the changes to VM state are (a) volatile (b) minimal
(c) non-interfering with normal ProxyVM operation. All of this is
consistent with the Qubes OS system design principles.

>
>
>> Frankly, much better than an instruction manual, or putting all of the
>> stuff in /rw/config/firewall stuff, because it being a package, it can
>> be updated regularly, given a repo containing the packages.
>
> Yes, you were suggesting that people incorporate your repo,

Wut. I don't even /have/ a repo.

Seriously, do you really dislike my work so much, that you need to find
100% fake reasons to smear it?

> while pretending the Qubes-approved solution didn't exist.

I never pretended there were no other solutions.

Frankly, this sort of snap, baseless remark, it seems more like you have
some sort of antipathy against me, or my program, for some reason.

>
>
> Its the /only/ loop in that script ...and boy is it ugly. :)

Give a line number please.

I have that file open right here, and there is absolutely no busy loop
in it. The only loop in the script has a nice "break" in it, and
executes at most for two iterations (that is, of course, obvious, IF you
understand the code!).

>
>>
>>> * Marketing hyperbole like "leak-proof" should be replaced with terms
>>> like "anti-leak"
>> If you think it's possible to have this VPN leak, then prove you can
>> cause a leak, and — if you succeed — I will plug the leak.
>
> Why move the goalposts? You explain why the existing solution, which
> is very unlike your complex set of rules,

Complex compared to what? 4 rules are not "complex", when you have more
rules in the scripts of the official VPN documentation.

> Lets "collaborate"? How disingenuous...

OK then, you are also welcome not to collaborate with me.

>
> We already have a Qubes-approved solution that is considered secure.
> You did not seek to package, improve, criticize or even /acknowledge/
> it before you started suggesting people integrate your repo into their
> templates! That, quite frankly, is suspicious behavior reminiscent of
> the "bum rush" and whether its inadvertent or not isn't my concern.
>
> If this seems uncouth to you, let me provide a reminder that this is a
> project where Joanna has advised we should distrust even ITL staff.
> Its advice that smartly sets the parameters of skepticism for just
> this sort of occasion.

There's healthy distrust, and then there's what you are doing, which is
finding specious pretexts and faulty reasons to dislike something I
wrote, which I made freely available.

So, thank you for your feedback, but you have not given me anything I
can use to make my program better or to help the users of my program.
In the future, try to give feedback that is more consistent with those
two goals. Or send a pull request — that talks way louder than
insinuations and pretexts.

--
Rudd-O
http://rudd-o.com/

[Chris Laprise]

Now that is something interesting. So the Qubes firewall is supposedly
bad. And we can let most users suffer whatever consequences when they
block traffic with sys-firewall, because only our specific VPN
application matters??

Keeping in mind that the default policy of FORWARD is DROP, we should
also consider whether a stream of iptables commands is too slow to be
secure. And if so, ask why 1) the user firewall rules are in script
format; Or why 2) the commands aren't all combined for an
iptables-restore; Or why 3) the chains aren't started with a temporary
REJECT while they are being populated. ANY. ONE. Of these will address
the issue for VPNs and all the other use cases.

'OOPS!'

Here is bog-standard advice for properly handling firewall rules in Fedora:

https://fedoraproject.org/wiki/How_to_edit_iptables_rules

Or how about:
$ cat internal-qubes-rules qubes-user-rules iptables-commit-cmd |
iptables-restore


At this point, we all need to know if Qubes firewall will be fixed in a
timely fashion. I am wondering what the heck "reasonably secure OS" is
supposed to mean in this context.


Chris

[Manuel Amador (Rudd-O)]

Nope. It's actually pretty good, and it was the inspiration for my
work. Getting leakproof VPNs is a hard job. The official documentation
for the firewall is as good as you can get, without hard core networking
work.

> And we can let most users suffer whatever consequences when they block
> traffic with sys-firewall, because only our specific VPN application
> matters??

I don't know what you mean. "Most users", "suffer", "consequences" when
they "block traffic". I have zero idea what this means with regards to
my work. Most users don't actually write shell scripts to do basic
things like VPN. "Most users" are not even the target of work like VPN
systems. The target market for such work is users who want provable
privacy. That is the sort of work that I endeavored to do, and now I
have delivered it.

>
> Keeping in mind that the default policy of FORWARD is DROP, we should
> also consider whether a stream of iptables commands is too slow to be
> secure.

Yes, the document should probably be updated to reflect that.

> And if so, ask why 1) the user firewall rules are in script format;

That isn't the case within Qubes OS. Qubes OS firewall adds / changes
rules atomically via iptables-restore.

> Or why 2) the commands aren't all combined for an iptables-restore;

They are in Qubes OS.

IF you are critiquing my work again, then I have to say you are
technically correct, as the DNS rules my work adds (during OpenVPN "up")
are not atomically added via iptables-restore.

That fact is not relevant to the promise of leak-proofness that my work
makes. The only *relevant* rules that get added during VPN connection,
are two DNS rules. Any DNS packets sent by downstream VMs will be
blackholed in the meantime, so, well, leakproof like I said from the
beginning. It's okay to flush the specific routing table for DNS that
my program creates, and then to add rules non-atomically, as DNS packets
coming in between the flush and the rules will get dropped and not
routed anywhere useful.

If you look closely at my work — this is not an accident, but a
deliberate outcome of my study of the problem — during OpenVPN "up", the
DNS rules are added before the routes are added, which has the side
effect of DNS packets being routed nowhere until the routes are added.
So non-atomic modifications to the firewall are fine in this case. It's
all in the `qubes-vpn-interface-control.in` script for anyone to see.

You are welcome to verify these claims with tcpdump (I did it too).

You are also welcome to send pull requests to make the rule addition atomic.

> Or why 3) the chains aren't started with a temporary REJECT while they
> are being populated. ANY. ONE. Of these will address the issue for
> VPNs and all the other use cases.

No need to, because the DNS packets get blackholed until the rules are
added.

> 'OOPS!'

Oops about what? Unlike the official Qubes VPN documentation, which
counsels people to write scripts that make non-atomic modifications to
their firewall, which actually and demonstrably have a leak between
Qubes firewall updates and VPN rules setup, my work doesn't leak traffic
in-between the addition of iptables rules.

(See why the custom routing table is useful?)

I mean, this you could verify with tcpdump. Which I did. So what are
you oopsing about? Or are you having a kernel panic in your head? :-)

>
> Here is bog-standard advice for properly handling firewall rules in
> Fedora:

Thank you. I await the pull request that implements them :-D

Now, if you could tone down the gratuitous arseholeish behavior, and
substitute it with actual actionable evidence for your aversion to my
work, or better yet, improvements to my code, that would be amazing.

Let's see if that positive change in behavior materializes.

--
Rudd-O
http://rudd-o.com/

[Chris Laprise]

On 10/13/2016 09:31 PM, Manuel Amador (Rudd-O) wrote:
>
> Oops about what? Unlike the official Qubes VPN documentation, which
> counsels people to write scripts that make non-atomic modifications to
> their firewall, which actually and demonstrably have a leak between
> Qubes firewall updates and VPN rules setup, my work doesn't leak traffic
> in-between the addition of iptables rules.

The qubes-firewall-user-script is a feature of Qubes firewall. And its
one of the original Qubes docs that encourage people to use it. So, yes,
there is a vulnerability in Qubes firewall, and it should be noted
foremost in the Known Issues for the project.

The VPN use case is probably one of the least-vulnerable examples of
leakiness in Qubes firewall, because it requires multiple failures to
line up in a small window. That means non-VPN use cases are probably at
least as vulnerable. Its the underlying problem which is my overriding
concern.

Chris

[Marek Marczykowski-Górecki]

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

On Thu, Oct 13, 2016 at 11:22:08PM -0400, Chris Laprise wrote:
> On 10/13/2016 09:31 PM, Manuel Amador (Rudd-O) wrote:
> >
> > Oops about what? Unlike the official Qubes VPN documentation, which
> > counsels people to write scripts that make non-atomic modifications to
> > their firewall, which actually and demonstrably have a leak between
> > Qubes firewall updates and VPN rules setup, my work doesn't leak traffic
> > in-between the addition of iptables rules.
>
> The qubes-firewall-user-script is a feature of Qubes firewall. And its one
> of the original Qubes docs that encourage people to use it. So, yes, there
> is a vulnerability in Qubes firewall, and it should be noted foremost in the
> Known Issues for the project.

ip_forwarding is disabled for the time of reloading rules.

Anyway, guys, please. Both solutions are fine.
One is easier to understand, convert to other VPN software and apply to
ProxyVM without modifying any template. The other one is OpenVPN
specific (at least currently) and easier to package (so do not require
copying any script by the user manually). Technical details here (more
iptables modifications vs separate route table) are just technical
details. Both approaches should work.

The nice thing of manual one (in current shape) is also blocking traffic
going from ProxyVM itself (and not originated by VPN software). But it
should be trivial to add the same to the other one. This should not
affect AppVMs behind such ProxyVM in anyway.

- --
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

iQEcBAEBCAAGBQJYAMmSAAoJENuP0xzK19csNroIAJpPS2jnDHdUBMKImgEMTzJZ
AWtgDbMpUpYDT7aX+LC8W84DrNHciDfbOhbNaVwxOgLX2iSd5iafv62M73D3oSsr
2+nO5isSnpY72CnJZgxPiS5jZ0R6WoF5zQcuDx3PREgU4Nr0hKCUQbITAMRhW6I+
XF3lemLX9InUzowYFgLFxc+8x1N0FSBToFor73W1tBFZI5SuS0mYoTCLsncFTBDC
QGOGd74V24aoQv3y++gD/wwaME8+oRLv5wqun75DuKx+hcSXUJEfwouemfKsyEva
8R42R1ZaF671jL+POORZPKL+AnLvrxwFC+FnArOQtt2STL5lrIcKW64PR5Iju8k=
=CCiA
-----END PGP SIGNATURE-----

[pleo...@gmail.com]

What im doing wrongso so its not working on fedora-23-minimal
i follow this steps

1.install openvpn in fedora minimal template
2.copy to fedora min template qubes-vpn*.noarch.rpm that i build in git qubes
3.sudo dnf install qubes-vpn*noarch.rpm && mkdir /rw/config/qubes-vpn
4 copy VPN .ovpn config files there
5.create file qubes-vpn.creds 1 line username 2 line pass
6 mv vpn-config.ovpn qubes-vpn.conf
7.edit qubes-vpn.conf and add

auth-user-pass qubes-vpn.creds
auth-retry nointeract

8.create vpn vm from fedora minimal - check box proxy vm trugh sys-fireewall
9 in VPN vm i add qubes-vpn to service
1- add firewall restrict in firewall tab * port
11 test config : openvpn --config qubes-vpn.conf SUCCES connect
12.shutdown VPN vm
13 set WORK VM to use VPN insted sys-firewall
14 start WORK vm
15 VPN starts automaticaly
16 Firefox in WORK start

and it wont connect

[epic...@gmail.com]

Hello, what is the difference between this implementation and just following the VPN guide on the Qubes website? Both seem to create a proxyVM.

https://www.qubes-os.org/doc/vpn/

Is your version more leak proof, if so, how?

[Manuel Amador (Rudd-O)]

On 10/14/2016 03:39 PM, pleo...@gmail.com wrote:
> What im doing wrongso so its not working on fedora-23-minimal
>
> i follow this steps
>
> 1.install openvpn in fedora minimal template
> 2.copy to fedora min template qubes-vpn*.noarch.rpm that i build in git qubes

> 3.mkdir /rw/config/qubes-vpn

> 4 copy VPN .ovpn config files there
> 5.create file qubes-vpn.creds 1 line username 2 line pass
> 6 mv vpn-config.ovpn qubes-vpn.conf
> 7.edit qubes-vpn.conf and add
>
> auth-user-pass qubes-vpn.creds
> auth-retry nointeract
>
> 8.create vpn vm from fedora minimal - check box proxy vm trugh sys-fireewall
> 9 in VPN vm i add qubes-vpn to service
> 1- add firewall restrict in firewall tab * port
> 11 test config : openvpn --config qubes-vpn.conf SUCCES connect
> 12.shutdown VPN vm
> 13 set WORK VM to use VPN insted sys-firewall
> 14 start WORK vm
> 15 VPN starts automaticaly
> 16 Firefox in WORK start
>
> and it wont connect

I need more information. Things that I may find useful to help you:

* A snapshot of your journalctl -b in the ProxyVM.
* Your VPN configuration (without any secret credentials).

Thanks!


--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

My version is free of firewall rule addition races, and it's easier to
deploy.

The limitation is that my work only works IF you use OpenVPN as VPN client.

--
Rudd-O
http://rudd-o.com/

[pleo...@gmail.com]

my vpn connection is good bcs its connect
openvpn --config qubes-vpn.conf
its something with your script,have you test it whith fedora minimal?

[Manuel Amador (Rudd-O)]

On 10/16/2016 01:03 AM, pleo...@gmail.com wrote:
> my vpn connection is good bcs its connect
> openvpn --config qubes-vpn.conf

That's not what I asked for.

Please give me the information required by the Troubleshooting section
of the README.md file in the project

Otherwise I cannot debug the problem for you and you are on your own.

> its something with your script,have you test it whith fedora minimal?

Yes, I use it with Fedora minimal.

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

Apologies for the reply to self, but I have received great news.

The first piece of great news is that a user of Qubes VPN found a bug
that made it impossible for Qubes VPN to work with tun-style VPN
providers. We have fixed that bug thanks to his cooperation, and you
can see the result of our bug report and conversation here:

https://www.reddit.com/r/Qubes/comments/57acz8/add_a_leakproof_vpn_to_your_qubes_os_with_this/

The second piece of great news is that, based on what he reported there,
ABSOLUTELY NO TRAFFIC ever leaked from his VPN-protected AppVM to any
sort of network device, as the VPN VM still prevented the traffic from
going anywhere else except over the VPN.

That means: even under an environment where a critical bug rendered VPN
operation impossible, Qubes VPN still managed to prevent leaks 100%.

I am quite happy to see that the engineering gone into this thing
actually paid off big time.

Have you tried Qubes VPN yet?

--

Rudd-O
http://rudd-o.com/

[cyrinux]

Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no problem, this seems perfect ;)

[Manuel Amador (Rudd-O)]

On 10/27/2016 09:15 AM, cyrinux wrote:
>
> Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no problem, this seems perfect ;)

Thank you very, very much. You are very kind for taking the time to
give public appreciation for my work :-)


This is the stuff I live for.


--
Rudd-O
http://rudd-o.com/

[Robert Mittendorf]

Just saw the Qubes VPN project right now.

Quick-reading the tutorial I have to questions:

1) why does the VPN-VM need to be allowed to do DNS, if DNS requests are
routed through the VPN. Is it just in case the VPN server it wants to
connect to is defined by hostname instead of IP?
2) why is the recommendation to allow all hosts for the VPN server (and
not only the VPN servers IP)?

thank you

[Manuel Amador (Rudd-O)]

On 10/27/2016 12:03 PM, Robert Mittendorf wrote:
> Just saw the Qubes VPN project right now.
>
> Quick-reading the tutorial I have to questions:
>
> 1) why does the VPN-VM need to be allowed to do DNS,

The VPN VM does not need to be allowed to do DNS. You can set an IP in
its configuration and then no DNS is needed.

I will expand the instructions to indicate that.

> if DNS requests are routed through the VPN. Is it just in case the VPN
> server it wants to connect to is defined by hostname instead of IP?

No. The DNS requests of the chained AppVMs are routed to the DNS
servers declared by the VPN server. The DNS requests of the VPN VM
itself are routed to the DNS servers of the NetVM that is upstream of
the VPN VM.

> 2) why is the recommendation to allow all hosts for the VPN server
> (and not only the VPN servers IP)?

No reason. I will clarify that there's no need to do that.

>
> thank you
>

Thank you for helping me clarify the documentation.


--
Rudd-O
http://rudd-o.com/

[SEC Tester]

Hey Rudd-O,

Thanks for your effort and great contribution to the Qubes community. Not sure why Chris was critical, especially without specifically showing evidence of any problems. Maybe just a troll?

I haven't tried your program out yet, Im keeping it as my backup option, as im still hoping to find a way to get my AirVPN GUI to work. I would prefer a GUI over a CLI, especially when i might want to switch servers quickly or look at my stats.

As you seem like such an expert on this, i was hoping you could have a look at my post, and see if you could workout whats going wrong?

https://groups.google.com/forum/#!topic/qubes-users/T0wbCuIgISg

If you have the time that would be Awesome! Cheers.

[Manuel Amador (Rudd-O)]

I don't really know how that VPN software works, honestly.


--
Rudd-O
http://rudd-o.com/

[motech man]

On Wednesday, October 12, 2016 at 4:35:53 PM UTC-5, Manuel Amador (Rudd-O) wrote:
> It gives me great pleasure to release the first iteration of the
> leakproof Qubes VPN.
>
> https://github.com/Rudd-O/qubes-vpn
>
> This package allows you to set up a leakproof OpenVPN VM on your Qubes
> OS system. All VMs attached to the VPN VM are automatically and
> transparently routed through the VPN. DNS requests do not hit the NetVM
> they get routed through the VPN instead.
>
> Users and developers welcome to contribute to the project in any way you
> can!
>

> --
> Rudd-O
> http://rudd-o.com/

First, I want to thank you for putting this together. Without people like you this community would not move forward nearly as fast.

I'm pretty new here, and this is somewhat of an old thread. I wanted to offer some feedback and solicit some advice if you have any to offer.

I tried to implement the cli vpn solution mentioned in the docs on on a tutorial video but it doesn't work. The vpn itself does, but I believe there's an issue at the iptables level. It's the last step of the process.

I first used a debian template as I am more familiar with that than fedora. When that didn't work I tried with fedora 23 (I'm using a qubes os version 3.2 and just upgraded the kernel to 4.9 which works better for my kaby-lake system).

I'm not very familiar with iptables so my trobleshooting stopped at making sure the scripts parsed the correct DNS args from the openvpn security-script.

The symptom is all notifications appear as expected, the security script runs, the rc.local fires off the process properly but I have no network connectivity. I noticed the comment in the iptables / DNS script that says "disallow outbound traffic" or something like that.

I am now going to setup the VPN with the GUI method just to move on for now, but really want the failsafe, anti-leak advantages of the cli method.

And suggestions on figuring out what is wrong?

[motech man]

On Wednesday, October 12, 2016 at 4:35:53 PM UTC-5, Manuel Amador (Rudd-O) wrote:
> It gives me great pleasure to release the first iteration of the
> leakproof Qubes VPN.
>
> https://github.com/Rudd-O/qubes-vpn
>
> This package allows you to set up a leakproof OpenVPN VM on your Qubes
> OS system. All VMs attached to the VPN VM are automatically and
> transparently routed through the VPN. DNS requests do not hit the NetVM
> they get routed through the VPN instead.
>
> Users and developers welcome to contribute to the project in any way you
> can!
>
> --
> Rudd-O
> http://rudd-o.com/

I tried to make the rpm package you posted on github, but the build / compile / prerequisites necessary to do so were not native to the Fedora 23 template out of the box, and you didn't say what were. I am also unfamiliar with Fedora so I don't know what packages to include. Bottom line: I didn't make the rpm.

I had resolved myself to just start the vpn manually for now, but reviewed the qubes firewall user script and noticed the last line referred to eth0 (a device) rather than an upstream virtual reference. So I commented out the last line ONLY, the "iptables output eth0..." and vpn now works as per the video tutorial -as best I can tell- Not sure if I get all the intended protection or if that last line is necessary and just needs to be altered around the eth0 device dependency or not. Hopefully it's more secure than the GUI / Network Manager approach, which I couldn't use either with my VPN as they don't provide a "user cert", and the network manager doesn't handle all the variations of the .ovpn files directly.