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/
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/b7c01ccc-7a85-e86d-b1d8-97a8bfc3b101%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.
