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
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/b9227f71-03cd-6271-5801-4f55eac043fe%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
