How to force AppVm to only use Proxy-VPN connection ?

[balooney]

the basic network is sys-net which is connected to sys-firewall

if you connect your AppVm 'personal' with it you ll
use your original IP adress.
sys-net < sys-firewall < personal

thats why I created a ProxyVM named 'vpn'

my AppVm 'Personal' has this ProxyVM named 'vpn' selected as NetVM
sys-net < sys-firewall < vpn < personal

if I do an IP check I get the IP from the vpn server I selected in my
'vpn' network manager.

PROBLEM
my real IP gets shown if I do not connect to any vpn server in my 'vpn'

that means my 'personal' appVM connects with the sys-firewall if im not connected to any vpn server. (the proxyVM 'vpn' is still running)

how can I force my appvm to not connect to the internet of my sys-firewall and only with the vpn ?

[Manuel Amador (Rudd-O)]

I have a solution for this. Gimme a second until I upload it to Github.

--
Rudd-O
http://rudd-o.com/

[Chris Laprise]

This requirement is already satisfied in the Qubes VPN doc:

https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

The scripts will stop non-VPN traffic and make sure that DNS operates
through the VPN instead of going around it.

Chris

[pleo...@gmail.com]

Maybe try this

sudo gedit /etc/NetworkManager/dispatcher.d/vpn-up


#! /bin/bash
REQUIRED_CONNECTION_NAME="VM uplink eth0" ##or change to your conection name
VPN_CONNECTION_NAME="example.vpn.com"
default_conn=$(nmcli con show --active | grep "${REQUIRED_CONNECTION_NAME}")
vpn_conn=$(nmcli con show id | grep "${VPN_CONNECTION_NAME}")
if [ "${default_conn}" -a ! "${vpn_conn}" ];
then
nmcli con up id "${VPN_CONNECTION_NAME}"
fi


#### change VPN_CONNECTION_NAME to vpn domain

Save it
chmod 755 vpn-up


gedit /etc/NetworkManager/system-connections/"example.vpn.com_"

If password type authentification change this section

[vpn]
....
connection-type=password
password-flags=0
....
[vpn-secrets]
password=your_password

Save it

After reboot it connects automaticaly.But its not the best way bcs the password is in plain and script is 755 privilages.But it works.

Then you shold edit firewall settings
VPN> VM settings > firewall >
add ip:port vpn
add ip vms
add localhost
rest tafiic deny

[Manuel Amador (Rudd-O)]

On 10/12/2016 06:02 PM, balooney wrote:

> how can I force my appvm to not connect to the internet of my sys-firewall and only with the vpn ?

As promised:

https://github.com/Rudd-O/qubes-vpn

This package allows you to set up a leakproof OpenVPN VM on your Qubes
OS system. All VMs attached to the VPN VM are automatically and
transparently routed through the VPN. DNS requests do not hit the NetVM
they get routed through the VPN instead.

Users and developers welcome to contribute to the project in any way you
can!

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 10/12/2016 07:58 PM, Chris Laprise wrote:
>
> This requirement is already satisfied in the Qubes VPN doc:
>
> https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts
>
>
> The scripts will stop non-VPN traffic and make sure that DNS operates
> through the VPN instead of going around it.

True, technically, someone reading an anatomy manual /could/ succeed in
performing surgery.

I prefer to release software that solves the issue without the user
having to cobble together scripts and whatnot, which has more of an
opportunity to allow for (fatal, in some cases) error. Furthermore,
user scripts that people put on a VM once and forgot about them, are
bound to remain unmaintained, whereas with packaged software, there's
the opportunity for me to release updates that work with future Qubes OS
versions.

That doc is also like 20 pages long when printed out. It's a really
long set of instructions. Why not a drop-in package, and then a config
file, and off to the races we go? Seems much simpler to me.

--
Rudd-O
http://rudd-o.com/

[Chris Laprise]

Its 6 pages, 4 if you only count the iptables/script section. And its
mostly cut-and-paste, so calling it "surgery" is another whopper.

But I do agree about the packaging... you could have packaged the
existing solution, perhaps?

If it does work, then is it preferable to withhold the solution known to
you (but 'complicated') so you can tell people to wait while you whip
something else up?


Chris

[entr0py]

Manuel Amador (Rudd-O):

@Chris @Manuel:
Thanks to both of you for your contributions. (Almost) everything Manuel said is correct. It's also true that Chris has unfairly been a target of criticism for his documentation which is really no more verbose than is necessary. His instructions allowed me to "perform surgery" :) many months before the availability of a drop-in solution.

Regarding Manuel's last point about simplicity: A package may be easier to install than a lengthy step-by-step but not necessarily easier to understand. For a certain subset of Qubes users who require knowing what changes are being made to their system, a package requires reading (sometimes complex) code, while a list of iptables rules are rather self-explanatory.

That said, following Chris' guide was a great learning experience. I look forward to studying Manuel's repo as well.

[Chris Laprise]

There's really no reason why the VPN doc solution can't be packaged. No
one was asking for that, and I was actually getting berated for not
creating an experience that was educational enough (my sin was in
supplying working scripts with comments instead of just the comments).

But Marek is clearly very receptive to the idea of packaging VPN helper
code, so I shall channel myself in that direction. I am all for reducing
human error, which is why I insisted on a fully scripted solution
against protests that users should write their own and hard code their
IP addresses.

Also, I really don't think its appropriate to take a security-critical
issue like this and ignore the existing (working) solution on the basis
of 'OMG no package! Hey kids, add my repository to your template!'
Someone offering technical solutions here is presumed to be
knowledgeable, not ignorant, so its puzzling to see someone dismissing a
working solution in such a manner.

Finally, I have posted some concerns about Manuel's package that you
should consider:
https://groups.google.com/d/msgid/qubes-users/b9227f71-03cd-6271-5801-4f55eac043fe%40openmailbox.org


Chris

[Manuel Amador (Rudd-O)]

On 10/12/2016 11:37 PM, Chris Laprise wrote:
>
> Its 6 pages, 4 if you only count the iptables/script section. And its
> mostly cut-and-paste, so calling it "surgery" is another whopper.

It's full of opportunities for people to make mistakes.

>
> But I do agree about the packaging... you could have packaged the
> existing solution, perhaps?

I packaged something better. My option has user notifications for
connection and disconnection, as well as full blackholing as soon as the
VM starts, so no chance for any leak at any point. My option is also
compatible with ProxyVM firewall rules.

>
> If it does work, then is it preferable to withhold the solution known
> to you (but 'complicated') so you can tell people to wait while you
> whip something else up?

I don't understand. Mind rephrasing?


--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

Your document was educational enough that it got me started on my VPN
package. It's really good. It just needs fine attention to detail. It
should be packaged. That is what I have done, with major modifications
to integrate well into Qubes OS.


--
Rudd-O
http://rudd-o.com/