ship Qubes VPN scripts by default

[adrelanos]

https://www.qubes-os.org/doc/vpn/

Regarding Set up a ProxyVM as a VPN gateway using iptables and CLI scripts... There are way too many files one has to copy/paste to make this work. It's a lengthy process. I would like to come up with a pull request to simplify all of that.

Could we ship all the VPN related files default in Qubes? So the user would only have to add the OpenVPN config files as well as enable the vpn firewall mode using some setting?

Where does it fit? Into qubes-core-agent-linux package, other package or new package?

Related:
QubesOS/qubes-doc#530

//cc @tasket

[marmarek]

Where does it fit? Into qubes-core-agent-linux package, other package or new package?

I'd say new package. qubes-app-linux-vpn (openvpn?), or such.

[marmarek]

Where does it fit? Into qubes-core-agent-linux package, other package or new package?

I'd say new package. qubes-app-linux-vpn (openvpn?), or such.

[tasket]

I was already writing up a couple of ideas about that. :)

My preference is to call it "tunnel" support, which suggests its an adaptable set of features and not just for openvpn.

@marmarek - I was thinking about a couple modest patches to existing code...

1. A zero script solution would involve patches to qubes-firewall and/or qubes-setup-dnat-to-ns to
   accommodate the case of a restricted tunnel configuration. This would add firewall rules like those in
   the vpn doc to qubes-firewall, which are activated with a configuration option.
   DNS processing in the doc would be a natural compliment to qubes-setup-dnat-to-ns perhaps accepting
   a 'tunnel' or 'no-resolvconf' option.

This should be fairly easy to do in existing packages, even on a 4.0 release schedule. qubes-firewall would have a selectable tunnel restriction option that works in proxyVMs. qubes-setup-dnat-to-ns could get the ability to parse option vars, or this could remain a separate script.

The firewall and DNS involve more than half of the current vpn doc.

---

Beyond that, there is a nagging issue of openvpn no longer running nicely without a managed service...

2. Some basic process management for VPN client would help. One particular issue I've been addressing with people in qubes-users is openvpn 2.4's change in behavior causing the client to exit with errors when the link is interrupted instead of a re-connect attempt. To address this we can't put long-term loops in an rc.local script, so here are two working approaches:
   1. Use systemd-run for the client. Target would be a script with client and sleep delay in a while true loop.
   2. Create a "qubes-tunnel" service config. This could be similar to the one in Qubes-vpn-support where the main service file is generic and the .d subdir contains an openvpn-specific conf as a Qubes service, and confs for other clients can be added. Such a service is qualitatively different than attempting to use the various openvpn-specific services provided by Linux distros.

The latter option, if included with Qubes, resolves another chunk of the vpn doc where the client is started.

Additionally, changing the openvpn command line in the service config can eliminate the step of editing the client config file. The result would be a relatively compact and approachable howto guide.

---

Whether this is packaged separately or not isn't a big deal to me. Separately its just a few files, although I'd still anticipate changes to qubes-firewall.

[tasket]

I was already writing up a couple of ideas about that. :)

My preference is to call it "tunnel" support, which suggests its an adaptable set of features and not just for openvpn.

@marmarek - I was thinking about a couple modest patches to existing code...

1. A zero script solution would involve patches to qubes-firewall and/or qubes-setup-dnat-to-ns to
   accommodate the case of a restricted tunnel configuration. This would add firewall rules like those in
   the vpn doc to qubes-firewall, which are activated with a configuration option.
   DNS processing in the doc would be a natural compliment to qubes-setup-dnat-to-ns perhaps accepting
   a 'tunnel' or 'no-resolvconf' option.

This should be fairly easy to do in existing packages, even on a 4.0 release schedule. qubes-firewall would have a selectable tunnel restriction option that works in proxyVMs. qubes-setup-dnat-to-ns could get the ability to parse option vars, or this could remain a separate script.

The firewall and DNS involve more than half of the current vpn doc.

---

Beyond that, there is a nagging issue of openvpn no longer running nicely without a managed service...

2. Some basic process management for VPN client would help. One particular issue I've been addressing with people in qubes-users is openvpn 2.4's change in behavior causing the client to exit with errors when the link is interrupted instead of a re-connect attempt. To address this we can't put long-term loops in an rc.local script, so here are two working approaches:
   1. Use systemd-run for the client. Target would be a script with client and sleep delay in a while true loop.
   2. Create a "qubes-tunnel" service config. This could be similar to the one in Qubes-vpn-support where the main service file is generic and the .d subdir contains an openvpn-specific conf as a Qubes service, and confs for other clients can be added. Such a service is qualitatively different than attempting to use the various openvpn-specific services provided by Linux distros.

The latter option, if included with Qubes, resolves another chunk of the vpn doc where the client is started.

Additionally, changing the openvpn command line in the service config can eliminate the step of editing the client config file. The result would be a relatively compact and approachable howto guide.

---

Whether this is packaged separately or not isn't a big deal to me. Separately its just a few files, although I'd still anticipate changes to qubes-firewall.

[adrelanos]

Calling it tunnel is the way to go because then this can be potentially extended to any type of VPN, proxies and ssh. If it must be a new package, including tunnel in its name makes sense. I'd also suggest to change the group name from qvpn to tunnel.

Perhaps enabling this tunnel support through a qvm-service.

I also think it would be better to make small modifications to existing Qubes scripts since this needs to be called from qubes-firewall and/or qubes-setup-dnat-to-ns anyhow. Installing this by default would be great, so users don't need to install an additional package before they can start using Qubes with tunnels. This would have the advantage, that one doesn't ever have to touch clearnet before setting up the tunnel connection, i.e. would help with hiding Qubes (and potentially Tor as well) from ISPs.

---

What about a systemd unit file which comes disabled by default (through missing qvm-service file) and without ExecStart defined? Then users could define the ExecStart line as well as enable it. Or the systemd unit file would run a wrapper, which would parse a .d config, whereas the user can configure what binary to run inside the .d config.

---

Separately its just a few files, although I'd still anticipate changes to qubes-firewall.

Yes, I guess it would be some code "if tunnel support is enabled, run this script`.

---

@tasket I didn't know you're already on it, which is great! Sounds like you're already more into it than I am and you'd be working on this in near future? Since I have a lot on my plate, I would let you do it. Didn't intent to "steal" this task from you.

[adrelanos]

Calling it tunnel is the way to go because then this can be potentially extended to any type of VPN, proxies and ssh. If it must be a new package, including tunnel in its name makes sense. I'd also suggest to change the group name from qvpn to tunnel.

Perhaps enabling this tunnel support through a qvm-service.

I also think it would be better to make small modifications to existing Qubes scripts since this needs to be called from qubes-firewall and/or qubes-setup-dnat-to-ns anyhow. Installing this by default would be great, so users don't need to install an additional package before they can start using Qubes with tunnels. This would have the advantage, that one doesn't ever have to touch clearnet before setting up the tunnel connection, i.e. would help with hiding Qubes (and potentially Tor as well) from ISPs.

---

What about a systemd unit file which comes disabled by default (through missing qvm-service file) and without ExecStart defined? Then users could define the ExecStart line as well as enable it. Or the systemd unit file would run a wrapper, which would parse a .d config, whereas the user can configure what binary to run inside the .d config.

---

Separately its just a few files, although I'd still anticipate changes to qubes-firewall.

Yes, I guess it would be some code "if tunnel support is enabled, run this script`.

---

@tasket I didn't know you're already on it, which is great! Sounds like you're already more into it than I am and you'd be working on this in near future? Since I have a lot on my plate, I would let you do it. Didn't intent to "steal" this task from you.

[hyperfekt]

@tasket

One particular issue I've been addressing with people in qubes-users is openvpn 2.4's change in behavior causing the client to exit with errors when the link is interrupted instead of a re-connect attempt.

I'm not entirely sure what you're referring to, but I think I might just have stumbled upon the same thing and added QubesOS/qubes-doc#556, which is a good workaround for servers that don't change their IP. It might be advisable to also add a low connect-retry maximum to quickly take advantage of a regained connection (default is 5 minutes).

[hyperfekt]

@tasket

One particular issue I've been addressing with people in qubes-users is openvpn 2.4's change in behavior causing the client to exit with errors when the link is interrupted instead of a re-connect attempt.

I'm not entirely sure what you're referring to, but I think I might just have stumbled upon the same thing and added QubesOS/qubes-doc#556, which is a good workaround for servers that don't change their IP. It might be advisable to also add a low connect-retry maximum to quickly take advantage of a regained connection (default is 5 minutes).

[tasket]

@adrelanos - Thanks for the input! I'd be glad to post the necessary changes.

@hyperfekt - Thanks and commented on the PR. Between using a service and overriding the group setting this should take care of reconnection issues without the user having to consider IP-related changes.

[tasket]

@adrelanos - Thanks for the input! I'd be glad to post the necessary changes.

@hyperfekt - Thanks and commented on the PR. Between using a service and overriding the group setting this should take care of reconnection issues without the user having to consider IP-related changes.

[marmarek]

@tasket core-agent-linux repository is already "all and the kitchen sink" type of thing, which doesn't exactly ease its maintenance. This is why I prefer separate package. But if it isn't possible to easily integrate it (separate service(s) with appropriate ordering?), some modifications to core-agent-linux are ok too. For example add support for directory /rw/config/qubes-ip-change-hook.d, not just one file there. Or something similar in /etc.

Note that being separate package or not does not affect being it installed by default - we can do it in both cases.

As for other topics touched here, I believe @tasket and @adrelanos will come up with reasonable solution :)

[marmarek]

@tasket core-agent-linux repository is already "all and the kitchen sink" type of thing, which doesn't exactly ease its maintenance. This is why I prefer separate package. But if it isn't possible to easily integrate it (separate service(s) with appropriate ordering?), some modifications to core-agent-linux are ok too. For example add support for directory /rw/config/qubes-ip-change-hook.d, not just one file there. Or something similar in /etc.

Note that being separate package or not does not affect being it installed by default - we can do it in both cases.

As for other topics touched here, I believe @tasket and @adrelanos will come up with reasonable solution :)

[tasket]

@adrelanos In this PR I'm trying @marmarek 's suggestion but as "qubes-firewall.d" in firewall.py instead. It seems like this is better than "qubes-ip-change-hook.d", partly because of the name and user expectations (and latter might re-execute if somehow the upstream interface changes).

PS, doing it this way means less issues for us and less instructions for the user, and the sequence of execution is always where we want it (just before qubes-firewall finishes).

[tasket]

@adrelanos In this PR I'm trying @marmarek 's suggestion but as "qubes-firewall.d" in firewall.py instead. It seems like this is better than "qubes-ip-change-hook.d", partly because of the name and user expectations (and latter might re-execute if somehow the upstream interface changes).

PS, doing it this way means less issues for us and less instructions for the user, and the sequence of execution is always where we want it (just before qubes-firewall finishes).

[tasket]

@adrelanos I could use advice on the best approach to the .service files...

I had all of the openvpn specific settings in *service.d/50_openvpn.conf which made sense when distributing it from github... users could do what they wish with that file without repercussions. But the new service files will be managed by a Qubes package, so if the user deletes/renames 50_openvpn.conf it could re-appear on a future update; that would break the .service config.

So perhaps moving everything from 50_openvpn.conf into the main .service file will be best: The user can override settings by adding their own .service.d/30_something.conf without any meddling in the .service.d directory by package managers. Maybe also include a commented-out example file in .service.d to show which settings probably should be overridden when using a different vpn client.

[tasket]

@adrelanos I could use advice on the best approach to the .service files...

I had all of the openvpn specific settings in *service.d/50_openvpn.conf which made sense when distributing it from github... users could do what they wish with that file without repercussions. But the new service files will be managed by a Qubes package, so if the user deletes/renames 50_openvpn.conf it could re-appear on a future update; that would break the .service config.

So perhaps moving everything from 50_openvpn.conf into the main .service file will be best: The user can override settings by adding their own .service.d/30_something.conf without any meddling in the .service.d directory by package managers. Maybe also include a commented-out example file in .service.d to show which settings probably should be overridden when using a different vpn client.

[adrelanos]

Sounds good!

Maybe also include a commented-out example file in .service.d to show which settings probably should be overridden when using a different vpn client.

Yes, one mkdir command less for the user.

[adrelanos]

Sounds good!

Maybe also include a commented-out example file in .service.d to show which settings probably should be overridden when using a different vpn client.

Yes, one mkdir command less for the user.

[tasket]

Posted the initial commit:

https://github.com/tasket/qubes-tunnel

Not yet tested in tweaked/renamed form... It contains the 'full fat' code from Qubes-vpn-support, which means:

1. The R3.2 IP-correction routine exists in tunnel-restrict-firewall (its skipped on R4.0)
2. Login info handling is a little complicated; Capable of popping-up a user/pwd prompt if its missing on startup.

[tasket]

Posted the initial commit:

https://github.com/tasket/qubes-tunnel

Not yet tested in tweaked/renamed form... It contains the 'full fat' code from Qubes-vpn-support, which means:

1. The R3.2 IP-correction routine exists in tunnel-restrict-firewall (its skipped on R4.0)
2. Login info handling is a little complicated; Capable of popping-up a user/pwd prompt if its missing on startup.

[tasket]

Idea:

Add checks to qtunnel-setup 'pre-start' or qtunnel-connect 'up' to ensure certain firewall rules are in place; show a notify warning or fail if they're not present.

[tasket]

Idea:

Add checks to qtunnel-setup 'pre-start' or qtunnel-connect 'up' to ensure certain firewall rules are in place; show a notify warning or fail if they're not present.

[tasket]

Initial tests on debian-9 and fedora-26 are good.

[tasket]

Initial tests on debian-9 and fedora-26 are good.

[tasket]

@adrelanos The service is probably ready for separate packaging in R4.0-rc5. Looking for testing and comments now...

Steps:

1. Copy to template and run sudo bash ./install
2. Stop template and create proxyVM based on it
3. Enable qubes-tunnel Qubes service
4. Add OpenVPN config files to /rw/config/qtunnel
5. Run /usr/lib/qubes/qtunnel-setup --config
6. Restart proxyVM

I've tested it on R4.0-rc4 with debian-9 and fedora-26, but it could use a test or two on R3.2.

[tasket]

@adrelanos The service is probably ready for separate packaging in R4.0-rc5. Looking for testing and comments now...

Steps:

1. Copy to template and run sudo bash ./install
2. Stop template and create proxyVM based on it
3. Enable qubes-tunnel Qubes service
4. Add OpenVPN config files to /rw/config/qtunnel
5. Run /usr/lib/qubes/qtunnel-setup --config
6. Restart proxyVM

I've tested it on R4.0-rc4 with debian-9 and fedora-26, but it could use a test or two on R3.2.

[tasket]

@marmarek @adrelanos - Is there any chance this can make it in the R4.0 release? Interest in VPNs remains strong in qubes-users.

Instructions.

If there are adjustments you'd like to see I'll get them done.

[tasket]

@marmarek @adrelanos - Is there any chance this can make it in the R4.0 release? Interest in VPNs remains strong in qubes-users.

Instructions.

If there are adjustments you'd like to see I'll get them done.

[hyperfekt]

Excited for this! I'm thinking it would be neat for the Tunnel VMs to be DispVMs, and to be able to choose from a couple of scripts for each instantiation, so it's easy to switch locations without having to create a new VM for every single one. What do you think?

[hyperfekt]

Excited for this! I'm thinking it would be neat for the Tunnel VMs to be DispVMs, and to be able to choose from a couple of scripts for each instantiation, so it's easy to switch locations without having to create a new VM for every single one. What do you think?

[awokd]

@tasket , do those qubes-firewall.d scripts apply to both 3.2 and 4.0?

[awokd]

@tasket , do those qubes-firewall.d scripts apply to both 3.2 and 4.0?

[tasket]

@awokd - No, it is a 4.0 only feature.

[tasket]

@awokd - No, it is a 4.0 only feature.

[adrelanos]

I'll advice not to wait for me. Perhaps build the package, upload to unstable and ask the community on the mailing list to test this?

[adrelanos]

I'll advice not to wait for me. Perhaps build the package, upload to unstable and ask the community on the mailing list to test this?

[tasket]

@adrelanos OK, I've setup a testing Readme and started a list thread about testing:

https://groups.google.com/d/msgid/qubes-users/ee24f104-efbc-23f7-aca3-6be86104ddaf%40posteo.net

In the meantime we should think about how the VPN doc will be updated for current use. Maybe a notice added at the top of the CLI instructions linking to qubes-tunnel and/or Qubes-VPN-support.

[tasket]

@adrelanos OK, I've setup a testing Readme and started a list thread about testing:

https://groups.google.com/d/msgid/qubes-users/ee24f104-efbc-23f7-aca3-6be86104ddaf%40posteo.net

In the meantime we should think about how the VPN doc will be updated for current use. Maybe a notice added at the top of the CLI instructions linking to qubes-tunnel and/or Qubes-VPN-support.

[tasket]

PR adding a notice to the vpn.doc about qubes-tunnel:
QubesOS/qubes-doc#637

[tasket]

PR adding a notice to the vpn.doc about qubes-tunnel:
QubesOS/qubes-doc#637

[tasket]

@adrelanos I think we should consider reviewing qubes-tunnel soon and getting the new doc finalized. Do you have time?

[tasket]

@adrelanos I think we should consider reviewing qubes-tunnel soon and getting the new doc finalized. Do you have time?