Qubes VPN documentation limitations #1941

adrelanos · May 2, 2016

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?

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.

andrewdavidwong · May 2, 2016

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.

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 · May 2, 2016

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.

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?

adrelanos · May 2, 2016

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?

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?

marmarek · May 2, 2016

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?

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

adrelanos · May 2, 2016

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

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.

larrypachec · May 5, 2016

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.

@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%."

andrewdavidwong · May 5, 2016

@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%."

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 · May 5, 2016

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.

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.

larrypachec · May 5, 2016

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.

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 · May 5, 2016

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.

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

What you are most interested in:

fix shared VPN/Tor server leak bug - on bountysource

And also...

get in shape for Qubes - AppVMs only

And perhaps also...

Qubes ProxyVM support

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.

adrelanos · May 5, 2016

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

What you are most interested in:

fix shared VPN/Tor server leak bug - on bountysource

And also...

get in shape for Qubes - AppVMs only

And perhaps also...

Qubes ProxyVM support

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.

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:

mfc · May 6, 2016

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:

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 · May 6, 2016

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.

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.

Zrubi · May 6, 2016

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.

@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:
adrelanos/vpn-firewall#14

larrypachec · May 6, 2016

@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:
adrelanos/vpn-firewall#14

@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.)

adrelanos · May 6, 2016

@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.)

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

Zrubi · May 7, 2016

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

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 · May 8, 2016

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 ?

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"

larrypachec · May 8, 2016

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"

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:

you have to put another firewalVM between you VPN proxy and your NetVM
(which is overkill)
your VPN server must have fix IP (until firewall rules by DNS is not
solved)
your DNS queries are still can be an issue.

Zrubi

Zrubi · May 9, 2016

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:

you have to put another firewalVM between you VPN proxy and your NetVM
(which is overkill)
your VPN server must have fix IP (until firewall rules by DNS is not
solved)
your DNS queries are still can be an issue.

Zrubi

Worked on VPN-Firewall a lot. (commit)

Finalization of that work is currently blocked by #1985.

adrelanos · May 11, 2016

Worked on VPN-Firewall a lot. (commit)

Finalization of that work is currently blocked by #1985.

Finalization of that work is currently blocked by #1985.

This has been sorted out. (#1985 (comment))

adrelanos · May 11, 2016

Finalization of that work is currently blocked by #1985.

This has been sorted out. (#1985 (comment))

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

adrelanos · May 12, 2016

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

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.

tasket · May 22, 2016

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.

I prefer the stricter approach with iptables policy drop. To prevent things as unforseeable and obscure as FIN ACK / RST ACK Leak.
It does not enforce traffic originating from VPN-Gateway itself is 100% VPN.

adrelanos · May 22, 2016

I prefer the stricter approach with iptables policy drop. To prevent things as unforseeable and obscure as FIN ACK / RST ACK Leak.
It does not enforce traffic originating from VPN-Gateway itself is 100% VPN.

In my previous commend and in this comment I am discussing the approach from #1941 (comment).

Have IPv6 leaks been considered?
DNS traffic will go through whatever is configured in sys-net's /etc/resolv.conf?
VMs behind sys-net do not require /etc/resolv.conf or other changes, right?
What would happen if someone did that in sys-net? (The point of doing it in sys-net would be to make sure there won't ever be any clearnet traffic, all 100% VPN, including Fedora phone home #1814, yum, ntp, and what I might have forgotten.)

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 · May 22, 2016

In my previous commend and in this comment I am discussing the approach from #1941 (comment).

Have IPv6 leaks been considered?
DNS traffic will go through whatever is configured in sys-net's /etc/resolv.conf?
VMs behind sys-net do not require /etc/resolv.conf or other changes, right?
What would happen if someone did that in sys-net? (The point of doing it in sys-net would be to make sure there won't ever be any clearnet traffic, all 100% VPN, including Fedora phone home #1814, yum, ntp, and what I might have forgotten.)

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.

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

adrelanos · May 22, 2016

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

@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

unman · May 23, 2016