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

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




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 post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to