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
* 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
* Critique of existing solution stops at 'No packaging'; Oddly,
nothing pertaining to anti-leak abilities
So what I see thus far is that the concerns and requirements expressed
in issue #1941  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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.