search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
534 stars 47 forks source link

Qubes VPN documentation limitations #1941

Closed adrelanos closed 8 years ago

adrelanos commented 8 years ago

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?

andrewdavidwong commented 8 years ago

If the VPN breaks down, connections will still be possible in the clear.

Is a (partial) solution for this to set the VPN VM's firewall rules to allow connections only to the VPN server? In my own testing, this seems to work. Obviously, it could still allow non-VPN connections to the VPN server, but for many use cases, that doesn't matter.

Do we have tickets for a) and b)?

I don't see any that would count as duplicates. However, #1536 may be related to (a).

In meanwhile should we list these limitations (and link to the tickets) from the documentation?

Yes.

adrelanos commented 8 years ago

Is a (partial) solution for this to set the VPN VM's firewall rules to allow connections only to the VPN server?

It solves a) partially (mostly) and is far better than without that firewall rule. One could still be unlucky and connect to let's say a web server hosted on the same VPN IP. It however does not solve b) very well.

adrelanos commented 8 years ago

Since this also matters to Whonix, for Whonix 13 I implemented a solution to allow only user tunnel to connect to the open internet. (If VPN_FIREWALL mode gets enabled.) All other users not. Such a solution should also work in Qubes.

It has an issue with dns resolution. (Because then there is no clearnet DNS to resolve the VPN server DNS.) Direct IP address in VPN config works, but only for some types of VPN authentication. The SSL-alike VPN authentication is broken (it expects hostnames, not IP's).

Does that make sense?

marmarek commented 8 years ago

On Mon, May 02, 2016 at 03:50:32AM -0700, Andrew David Wong wrote:

If the VPN breaks down, connections will still be possible in the clear.

Is a (partial) solution for this to set the VPN VM's firewall rules to allow connections only to the VPN server? In my own testing, this seems to work. Obviously, it could still allow non-VPN connections to the VPN server, but for many use cases, that doesn't matter.

Specifying destination port in that firewall rule should help a lot. Still, probably some cases will not be solved (like VPN running on 443), but it's some improvement.

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

adrelanos commented 8 years ago

Yes.

Here is the documentation for Whonix 13 using the "only user tunnel is allowed to establish connections" method, that I just now finished testing.

https://www.whonix.org/wiki/Next#VPN_before_Tor

It's footnotes also link to various files that are shipped by default (package: usability-misc [1]) to ease this difficult process.

I can likely implement the same into the (to be packaged, to be made work in Qubes, etc.) VPN-Firewall. [2]

[1] https://github.com/Whonix/usability-misc [2] https://github.com/adrelanos/VPN-Firewall

larrypachec commented 8 years ago

I will contribute $500 to developer who will solve this issue, mainly I need avoid IP leak, For now I have placed in ProxyVM right before TorVM

/rw/config/qubes-firewall-user-script

iptables -I FORWARD 1 -o eth0 -j DROP
iptables -I FORWARD 2 -i eth0 -j DROP

is it enough ? And bulletproof ? it's seems to be working but I am still worried to use Tor. Have to be 100% before I will do.

andrewdavidwong commented 8 years ago

@larrypachec:

mainly I need avoid IP leak

It depends on what you mean by "IP leak." If you mean not exposing your real external IP address, Qubes-Whonix already does that. This issue is about something different (VPNs being used to hide Tor usage and not failing closed).

is it enought ? And bulletproof ? it's seems to be working but I am still worried to use Tor. Have to be 100% before I will do.

This warning is often given: "Whonix is experimental software. Do not rely on it for strong anonymity."

Nothing is "bulletproof" or "100%."

larrypachec commented 8 years ago

VPN gateway(ProxyVM) should stop forwarding if VPN disconnects.

My ISP should not know that I am using Tor.

For other users using only VPN, in moment when VPN disconnect, whole world see your real external by ISP assigned IP.

larrypachec commented 8 years ago

This was backed up on Debian using @adrelanos firewall

https://github.com/adrelanos/VPN-Firewall

perhaps this firewall could be rewritten to be working in Qubes.

adrelanos commented 8 years ago

VPN-Firewall fails closed but is currently also not solving b) (as per initial report in this thread).

I'll be writing a bug report against VPN-Firewall. Then you might decide to put a bounty on bountysource. And hope someone will contribute the code to fix this. I'd review and merge good quality patches. I might even fix it myself one day but don't hold your breath for it. It's not the highest priority for me.

adrelanos commented 8 years ago

There is quite a lot work in order to get vpn-firewall into shape for Qubes.

What you are most interested in:

And also...

And perhaps also...

On bountysource, overview: https://www.bountysource.com/trackers/990386-adrelanos-vpn-firewall

If someone decides to post a bounty for any of these tickets, I will inform the public about it by posting these on the Whonix blog.

mfc commented 8 years ago

sorry is it really the case that there are no existing VPN clients that fail closed? I feel like we are raising issues that may be solved by now in other places by projects that focus on this (please correct me if I'm wrong).

for example, the open source Bitmask client ((OpenVPN-based) fails closed:

Zrubi commented 8 years ago

a, A simple VPN connection will never ever be fail close. I understand that most user want a feature like a fail close, leak protected solution, but such a solution would involve much more components than a VPN tunnel.

What we can do here is to make it clear what is the purose of a simple VPN connection.

Zrubi commented 8 years ago

b, as I noted for case a; A simple VPN is not designed to hide things. It is designed to connect private networks together instead.

larrypachec commented 8 years ago

@mfc @Zrubi

As from my experience running Open VPN in terminal or in Network Manager, I do not know why such connection should be permanent ? It can happen easily,and not only by user wrong setup. That connecting to VPN can drop. Now user might think that he is browsing "anonymously" but he is browsing with real IP unknowingly.

@adrelanos

Actually what I am mostly interested is: https://github.com/adrelanos/vpn-firewall/issues/14

adrelanos commented 8 years ago

@mfc

sorry is it really the case that there are no existing VPN clients that fail closed?

OpenVPN does not fail closed which is the Libre Software one. There are proprietary, non-Free, provider specific VPN clients that do claim to fail closed. (Probably just covering a), not b).)

I cannot prove a negative (no VPN client exists that fails closed - well - maybe - besides bitmask), but in all that time I am having vpn-firewall on github and fail closed mechanism issue explained in the Whonix wiki, no one ever pointed me at a client that does. At the Tor 2015 winter dev meeting, I talked to a Swedish VPN company, I think it was mullvad. They are aware of the issue, that 's why they provide their own client. They also talked about plans to Open Source their client, however I don't know if they are really working on these plans.

I feel like we are raising issues that may be solved by now in other places by projects that focus on this (please correct me if I'm wrong).

for example, the open source Bitmask client ((OpenVPN-based) fails closed:

https://bitmask.net/

bitmask may be solving a) but I don't know if it will be solving b). It's on my todo list to ask about that.

bitmask is by the way not compatible with OpenVPN servers. (I deduced this from reading this ticket.) The number of bitmask servers is still very low and bitmask is not installable from official Debian repositories.

https://leap.se/en/source

(As I understand, leap.se is the vendor and not a separate VPN client, their only VPN client is bitmask.)

Zrubi commented 8 years ago

On 05/06/2016 05:13 PM, larrypachec wrote:

@mfc https://github.com/mfc @Zrubi https://github.com/Zrubi

As from my experience running Open VPN in terminal or in Network Manager, I do not know why such connection should be permanent ? It can happen easily,and not only by user wrong setup. That connecting to VPN can drop. Now user might think that he is browsing "anonymously" but he is browsing with real IP unknowingly.

Well OpenVPN has a config option: resolv-retry infinite which causing a permanent VPN conncetion. It will only drop if the server or the client close the connection properly. Any other cases will be handled by TCP itself means the VPN client will continue to send the packets to the tunnel - even if those packets are not delivered...

While this seems useless it will prevent some kind of data leak, and seammlessly "reconnect" (as you can note actually no need to reconnect) when the server available again.

Another thing that my VPN icon pack can help notice the dropped VPN sessions by displaying a red open padlock in case of the VPN session is not established. https://github.com/Zrubi/qubes-artwork-proxy-vpn

Zrubi

larrypachec commented 8 years ago

I come up with this idea, one could setup HVM to use instead ProxyVM (it might sound crazy,but I believe it will serve the purpose) In Debian HVM one can setup OpenVPN and also easily use adrenalos firewall

https://github.com/adrelanos/vpn-firewall/

my intentions is to have setup like this

sys-net - HVM Debian (instead ProxyVM "running only Openvpn) - AppVM

the issue with this is that Qubes does not allow me to setup HVM Debian as NetVM :/ Tried also with qvm-prefs but it gives me this error

VM '<QubesHVm at 0x114ed90 qid=24 name='Debian'>' is not NetVM

By setting HVM as proxy I could be sure that if VPN will drop my external IP will not be exposed.

Some suggestions ?

larrypachec commented 8 years ago

So just figure out a) can be solved with using "build in qubes firewall" it is possible use rule "Deny network access except paste here IP of VPN"

Zrubi commented 8 years ago

On 05/08/2016 10:23 PM, larrypachec wrote:

So just figure out |a)| can be solved with using "build in qubes firewall" it is possible use rule "Deny network access except |paste here IP of VPN|"

In this case:

Zrubi

adrelanos commented 8 years ago

Worked on VPN-Firewall a lot. (commit)

Finalization of that work is currently blocked by https://github.com/QubesOS/qubes-issues/issues/1985.

adrelanos commented 8 years ago

Finalization of that work is currently blocked by #1985.

This has been sorted out. (https://github.com/QubesOS/qubes-issues/issues/1985#issuecomment-218613224)

adrelanos commented 8 years ago

Progress on finalization of this work is now blocked by various bind-dirs.sh limitations. Help welcome! More info: https://groups.google.com/d/msg/qubes-devel/tcYQ4eV-XX4/J89DRLzOBQAJ

tasket commented 8 years ago

Could you answer @larrypachec 's question from May 5 @adrelanos ?

I see no reason why any Whonix-Qubes vm (or other Qubes vm) that is downstream from a vpn vm using those two firewall rules would be vulnerable.

adrelanos commented 8 years ago
adrelanos commented 8 years ago

In my previous commend and in this comment I am discussing the approach from https://github.com/QubesOS/qubes-issues/issues/1941#issuecomment-217220257.

I acknowledge, this approach has great potential for a solution that is a lot easier to set up in Qubes. Without all the configuration overhead for running OpenVPN under a specific user account. That approach still requires fully fledged documentation.

adrelanos commented 8 years ago

Related mailing list discussion: https://groups.google.com/d/msg/qubes-devel/9zR_plUWRMA/19sDdo9zAgAJ

unman commented 8 years ago

@mfc is quite right - this is reinventing the wheel. Not that that's necessarily a bad thing - maybe it's a softwheel. Almost all vpn appliances fail close and they use pretty simple techniques to do it.

I posted to the qubes-users list a year ago on this topic. Here's an improved version drawing on openvpn, but adjustable for pretty much any vpn. N.B I favour using a separate proxyVM to act as the vpn client, but this isn't necessary. It just makes it easier to have different traffic flows simultaneously. Remote server at X.X.X.X, with openvpn port 1194. (You need to have IP address for remote server: not uncommon.) tun0 with remote 10.9.0.1, client 10.9.0.2 Set up openvpn on the proxyVM to connect to the remote server. Add a static route to X.X.X.X via dev eth0.

Either use redirect-gateway def1 in the client config file, or (better) delete the default route altogether and add the gateway when the tunnel comes up: ip route [change|add] default via 10.9.0.2 dev tun0 proto static

Use the following rules on the proxyVM: iptables -P OUTPUT DROP iptables -I OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -o eth0 -d X.X.X.X -p udp --dport 1194 iptables -A OUTPUT -o tun0 -j ACCEPT

The 2nd rule restricts outbound eth0 to the openvpn server and vpn port. The 3rd allows all traffic down the tunnel. The policy is to drop.

Now if the tunnel drops the gateway route disappears, so there is no leakage. In any case rule 2 blocks any traffic except to openvpn port.

What about DNS queries, as raised by @Zrubi? To fix this you need to have a DNS server accessible through the vpn - either one provided or a publicly accessible server. Let's say this is Y.Y.Y.Y The simplest way is to insert new rules in PR-QBS chain in nat table: iptables -t nat -I PR-QBS -p udp --dport 53 -j DNAT --to-destination Y.Y.Y.Y:53 iptables -t nat -I PR-QBS -p tcp --dport 53 -j DNAT --to-destination Y.Y.Y.Y:53

This will rewrite the DNS destination, and the traffic will be routed down the vpn tunnel. (The same set up will work for a standalone VPN client - just put the DNAT rules in the OUTPUT chain in the nat table.)

The beauty of this setup (and the qubes networking model) is that it's trivially easy to have some qubes using the VPN while at the same time some use TOR or clearnet. Because there has been no change in the downstream qube, you can switch from vpn to clear, just by changing the netvm for that qube. Also, the same firewall constraints for a qube will apply on the tunnel as in clear.

This approach resolves both issues (a) and (b) raised by @adrelanos, and is easy to put in place. I don't use network manager, but I assume there is some hook mechanism and someone who knows it would be able to expand the VPN guide to include this.

There is a risk here in that the iptables rules allow traffic to IP and port for VPN server, and feasibly an adversary could commandeer this. I have seen systems which insert this rule immediately prior to attempting the vpn connection, and remove it in case of failure. A simple bash script will do it, but it's possible that network manager has a suitable hook

Zrubi commented 8 years ago

On 05/24/2016 01:28 AM, unman wrote:

@mfc https://github.com/mfc is quite right - this is reinventing the wheel. Not that that's necessarily a bad thing - maybe it's a softwheel. Almost all vpn appliances fail close and they use pretty simple techniques to do it.

As I see currently the blocking point is the Qubes firewall scripts. They not make it easy to completely change all the iptables ruleset.

There is a similar issue with the same problems: #1536

Laszlo Zrubecz

tasket commented 8 years ago

@unman Actually, I think its standard procedure to call 'qubes-setup-dnat-to-ns' script once a vpn connection is established and resolv.conf updated. This inserts/updates the dnat rules you mentioned.

Together with forward-blocking, this should cause an openvpn connection to always fail closed.

Testing this is going slowly, as I have to correlate tcpdumps on two interfaces to make sense of the dynamics -- one question I have is whether netfilter will route the dns packets to Forward under all reasonable operation and failure modes.

I'll post updates in the discussion thread.

Either use redirect-gateway def1 in the client config file, or (better) delete the default route altogether and add the gateway when the tunnel comes up:

Won't this prevent openvpn from re-connecting?

unman commented 8 years ago

@Zrubi I don't see this as a blocking point, because I don't encounter any issues in changing the rules. I have always found the current arrangements workable.

I put rules files in /rw/config, copy them to /etc/iptables and restore from rc.local on boot. The qubes-firewall service drops only INPUT and OUTPUT chains in filter, which isn't quite what you commented in #1536. Since I have very simple requirements for these chains, I flush and rebuild from the user-firewall script, and restore custom chains using the -n parameter. (You can, of course, use any commands in that script to control routing, forwarding, or interfaces.)

@ttasket That "standard procedure" requires resolv.conf to be updated. Using above method no change is needed on the downstream clients. So you can move qubes in and out of the vpn without any reconfiguration.

Had this on bench test some time ago with no leakage. I'd be surprised if things have changed.

Won't this prevent openvpn from re-connecting?

No, because a static route has been set.

tasket commented 8 years ago

@unman

That "standard procedure" requires resolv.conf to be updated. Using above method no change is needed on the downstream clients. So you can move qubes in and out of the vpn without any reconfiguration.

Then maybe we aren't understanding each other...

What I'm describing also takes place completely in the vpn vm. The only 'trick' is to have the vpn client update dns info, which is fairly easy (see script posted to qubes-users by olivier medoc) and natural, since the client is also fetching the dns addresses from the vpn server upon connection.

Of course, this has the effect of changing the nameservers for local programs in the vpn vm as well as how downstream dns gets routed. In the case of Qubes, we may not need or want the local effect (the one upside I can think of is its easier for vpn client to reconnect if original resolv.conf remains). In that case, we could have the vpn client run iptables dnat commands without the qubes script.

Had this on bench test some time ago with no leakage. I'd be surprised if things have changed.

Sounds encouraging.

Won't this prevent openvpn from re-connecting?

No, because a static route has been set.

Cool!

One thing that concerns me:

Use the following rules on the proxyVM: iptables -P OUTPUT DROP iptables -I OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -o eth0 -d X.X.X.X -p udp --dport 1194 iptables -A OUTPUT -o tun0 -j ACCEPT

...and...

iptables -I FORWARD 1 -o eth0 -j DROP iptables -I FORWARD 2 -i eth0 -j DROP

I feel like the former could be complementary to the latter (which I believe is a good basis for the solution). But restricting OUTPUT in exactly this way would also cause problems (how does dns get through)? I am inclined to use just a couple general rules for dport 1194 and 53, omitting the address (which can change). We might also add a rule to INPUT to allow only related traffic...

unman commented 8 years ago

That approach to dns won't work for vpn clients that don't use resolv.conf like bitmask (there's a thread on this in the qubes-user list) whereas new PR-QBS rules will work in every case.

On the iptables front, yes the FORWARD restrictions offer belt and braces.

I don't allow outbound DNS from the proxy - that's why you need to have IP address for vpn server. You could implement a round robin in /rw/config, writing an entry to hosts file from rc.local, and updating the fw rules accordingly. If you must, I'd suggest opening DNS to specific trusted server.

@andrewdavidwong Isn't there enough here for updated documentation? Or a FAQ? These issues seem to come up on the mailing lists repeatedly.

andrewdavidwong commented 8 years ago

Isn't there enough here for updated documentation? Or a FAQ? These issues seem to come up on the mailing lists repeatedly.

Yes, that's what this issue is for. Pull requests are more than welcome!

unman commented 8 years ago

PR submitted

tasket commented 8 years ago

@unman Openvpn doesn't necessarily update resolv.conf; that's done with a user script. Your way can be applied just as easily in a script for openvpn, so I don't think it matters whether the client is openvpn or bitmask in this respect.

Your dnat example does leave dns untouched for local vpn vm programs, which I think is a plus. That traffic is better left outside the tunnel.

BTW, I discovered groups can be very easily used to filter packets... will post about that in the thread and then start work on a pull request of my own.

adrelanos commented 8 years ago

What about IPv6?

tasket commented 8 years ago

IPv6: Qubes firewall doesn't support it yet. I'm setting everything to DROP with ip6tables in my VPN firewall script.

I think it would make the most sense to support IPv6 for VPN VMs when Qubes in general supports it.

adrelanos commented 8 years ago

I guess it would be safer to add IPv6 blocking to the Qubes VPN documentation now so users won't experience leaks once Qubes supports IPv6?

marmarek commented 8 years ago

Qubes by default set policy DENY for IPV6 INPUT and FORWARD.

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

tasket commented 8 years ago

So far, inadvertent OUTPUTs have also been a concern for some here; so I'm trying to lock that down, too. But IMHO its a secondary issue. The main issue is to block Forwarding, I think.

We can do just fine by presenting forward-blocking in the firewall-user script as the main solution, but also mention further measures for preventing inadvertent access to/from the proxy vm itself (can mention IPv6 here).

I'd also not like to rely on the routing table for failing closed in any way. VPN clients like to manipulate the table automatically, the user may also have a provider that pushes problematic routing commands, etc. IMO, this is the firewall's job.

BTW, created new thread for the Qubes-vpn-support scripts I have up on github... https://groups.google.com/d/msgid/qubes-devel/57516C4B.4070305%40openmailbox.org

andrewdavidwong commented 8 years ago

Since this issue is only about the documentation, you might want to consider opening (or using) a different issue for anything that involves actual code.

tasket commented 8 years ago

Since the doc is instructing people to write code, references to existing solutions and examples will be hard to avoid. And y'all haven't been avoiding it.

andrewdavidwong commented 8 years ago

Ok, that's fine. It's just an organizational matter. If this issue is just about fixing the documentation, then it should be closed once the documentation is fixed, which could be inconvenient for anyone still trying to use it to track other things. (Also, documentation issues aren't tracked in the feature development tracker.)

On the other hand, if this issue has evolved beyond a documentation issue (has it?), then it should be retitled, relabeled, and properly tracked.

tasket commented 8 years ago

Just sent a PR.

Its an abbreviated version of my scripts and includes the important fail-closed protections.

It requires no hard-coding of IPs. In fact, no editing other than the openvpn config. I think this is more convenient, works better with larger VPN services, and is less error-prone.

I've also wondered if support for VPNs should be added to Qubes itself instead of handled with docs.

adrelanos commented 8 years ago

Please reference your pull requests, otherwise it's getting hard to follow this ticket. More so the more time passed.

PR by @ttasket: https://github.com/QubesOS/qubes-doc/pull/160

related ticket: document how to safely use Bitmask (FOSS VPN) https://github.com/QubesOS/qubes-issues/issues/2021

Zrubi commented 8 years ago

referring to the current documentation: https://www.qubes-os.org/doc/vpn/

It become more confusing than before.

I suggest to:

tasket commented 8 years ago

The new version is cutting and pasting 3 scripts verbatim. It could use more introductory verbiage but I don't see how it can be called confusing.

Prior version had the user assembling snippets of code into a self-constructed firewall script and manually parsing the following references:

X.X.X.X Y.Y.Y.Y $DEV $PROT $SVR $DNS

As a result they were bound to make mistakes and were stuck with all-static IP references. That is unrealistic with many VPN services that rotate among dozens of IPs; It could at the very least act as a glaring fingerprint on someone's network traffic.

The example uses openvpn, but is not technology specific except for step 2. If you can run your client under a group ID and have it pass DNS as an environment variable, then it will work with these scripts as-is (I think the user is capable of changing the openvpn command to something different). So perhaps that section should be re-labeled and explain that aspect: Its actually a general method of stopping leaks.

In step 2, we make a few offhand suggestions about the openvpn config file, and then show how to run the vpn-handler script. Its about 3 paragraphs--which is shorter than before. The language could be made more neutral while still using openvpn as an example.

There is also no mention of "leak proof" in the revised doc, so I don't see the point in railing against it. However the firewall references do claim to stop through-traffic / forwarding, which is accurate.

Finally, I think that showing a warning insinuating leaks cannot be stopped while using a VPN would be a grave error. It is far more accurate to say that VPN clients do secure a single link or tunnel, while preventing all other links is the role of the OS. Qubes is especially good at this, IMO. But that's why we have an example of configuring Qubes to do it.

What would really make documentation simpler is to remove the burden of describing what amounts to infrastructure. If Qubes included scripts like those in the doc, then it would just be a matter of referencing them.

In the meantime, I'll submit some changes to relabel and better explain the "iptables and openvpn" section.

unman commented 8 years ago

@ttasket @Zrubi is right - it seems more specific to openvpn than before, and I think would be better as a separate guide. Getting users to think about what they are doing and learning something about their network setup is better than giving them scripts to cut and paste. Because the new page doesn't explain what the issues are and how they might be addressed it's fairly mysterious why you would want to do things that way, which seems far more complicated than the other options. I like the idea of referring back to this discussion, because there is material here that isn't covered on the new page.

tasket commented 8 years ago

I feel like this is really more about aesthetics, because I'm the only one making specific references and examples (e.g. paying attention to details) in this discussion since yesterday. See next response...

Because the new page doesn't explain what the issues are and how they might be addressed it's fairly mysterious why you would want to do things that way

Well you can say that, but actually the firewall commentary was preserved as comments in the firewall script. So I find that statement odd.

Also, saying that cutting and pasting is bad is pretty bizarre when they are going to cut and paste anyway. You aren't trying to force them to type it all in as some kind of misguided "teaching", are you? The problem can be reliably automated.... there is no excuse here.

The firewall script and qubes-vpn-handler.sh should be in the vpn doc, or in Qubes, because they address the two crucial issues of blocking unwanted traffic and handling DNS while not setting users up for failure.