Closed adrelanos closed 8 years ago
@ttasket There is nothing wrong with your guide. And my opinion is not against such solutions. I only suggested to rearrange the VPN related documentations. Because the general VPN guide in Qubes is about to decide where to implement such service. Then the users must decide to use NetworkManager or CLI. Your guide should be linked under the CLI category and probably labeled as openVPN.
Another reason for the rearrangement that there are more VPN related solutions like: https://github.com/adrelanos/vpn-firewall/
Somehow Tor, and or Whonix solutions also related. Moreover - if you follow the mailing lists - there was already some other VPN specific discussions about various VPN clients under Qubes.
Zrubi... The guide is not about GUI-vs-CLI choice or devoted to GUI as I see it. And I am looking at a way to use the scripts with Network Manager.
Displaying openvpn
as a command does not suddenly make the guide specific. The overall number of lines devoted to openvpn shrank to 13 (WAS 18). They could use re-wording, which would cut that by half. Clearly, adding examples for other clients could be easily accommodated.
IIRC, Patrick was considering this solution as a reason to drop vpn-firewall development. My understanding is that qubes-vpn-handler is a replacement for vpn-firewall, but not vice-versa.
I don't feel like you're following this at a technical level, so I'm not going to debate this with you further.
Well, I'm following this because I was the one who originally created the VPN documentation long time ago. I was the one who tested and debugged the NetworkManager vs ProxyVM situation. And also created NM icons for Qubes VPN. Moreover I'm using several type of VPNs in ProxyVMs since the proxyVM actually exists in Qubes.
And what I see now is a messed up documentation around VPN I would also be able to simply revert back that page - but I do not want to throw away the work you (and others) did - trying to collaborate instead to create something useful...
Now I reviewed the page history and found the commit where the "mess" was started: https://github.com/QubesOS/qubes-doc/commit/bccd9558b36e286657449687912998743eb908e9#diff-b5237521e2a374e41f3f8a7cdad167da
So as I stated before I do not questioning your solution I just want to organize the VPN documentation better. To prepare for other more specific guides as well.
Participants in this thread [who have not subscribed to all qubes-issues and qubes-doc] may be interested to follow recent developments.
(Problem is, github automatic references like "ttasket referenced this issue a day ago" do not result in e-mail notifications so this is easily missed.)
What's left to do here? Perhaps best to create a follow up ticket if anything?
@adrelanos: Agreed.
can we ensure there is a table of contents / sections listed on the side of the VPN page? I think we used to have them and they are no longer for the VPN page. The ToC would have:
@mfc: Fixed.
great, thanks!
a) Qubes VPN documentation afaik does not fail closed. If the VPN breaks down, connections will still be possible in the clear. Which most likely is not what most users want since they want assurance the VPN will always be used.
b) Qubes VPN documentation is not suited to hide Tor. It does not claim it is, but using VPNs to hide Tor is something users often have in mind. (I infer this from the many questions about it from the Whonix forums.) This is because if a Tor entry guard is running on the same server as the VPN server, and if VPN breaks down, Tor may connect directly to the VPN if it happened to choose that as entry guard. This is not that unlikely, because a lot VPN providers support VPN port forwarding, use public IPs and people host Tor servers behind VPN's.
Do we have tickets for a) and b)?
In meanwhile should we list these limitations (and link to the tickets) from the documentation?