ANN: Qubes network server

[Manuel Amador (Rudd-O)]

Folks, it gives me great pleasure to announce the product of over two
years of work (primarily because I never paid enough attention to this
project to bring it to completion): Qubes network server.

The traditional Qubes OS networking model contemplates a client-only use
case. User VMs (AppVMs or StandaloneVMs) are attached to ProxyVMs, which
give the user control over outbound connections taking place from user
VMs. ProxyVMs in turn attach to NetVMs, which provide outbound
connectivity for ProxyVMs and other user VMs alike.

Qubes network server changes all that. With the Qubes network server
software, it becomes possible to make network servers in user VMs
available to other machines, be them peer VMs in the same Qubes OS
system or machines connected to a physical link shared by a NetVM. You
get actual, full, GUI control over network traffic, both exiting the VM
and entering the VM, with exactly the same Qubes OS user experience you
are used to.

This is all, of course, opt-in, so the standard Qubes OS network
security model remains in effect until you decide to share network servers.

Anyway, without further ado:

https://github.com/Rudd-O/qubes-network-server

Real easy: clone, build, install, test. I tested it with Qubes 3.1, but
it's very likely that it'll work fine in Qubes 3.2. I recommend you
test this on a Qubes machine that is not your main Qubes machine, but
the code does not do anything funky, and uninstalling the program should
be enough to revert your system back to its original state.

I hope we can turn this add-on into a core Qubes feature. As always,
contributions to the project — reports, code enhancements, pull
requests, other items — are very much welcome!

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

[Jeremy Rand]

Manuel Amador (Rudd-O):

Ooh, nice! This should be a huge benefit to usability for these use
cases -- while manual port forwarding via iptables is a thing, it's
really error-prone and time-consuming to debug. Thanks for your work on
this. (For anyone wondering, I haven't tested it due to lack of time at
the moment.)

Cheers,
-Jeremy

[Manuel Amador (Rudd-O)]

Update:

I have dramatically enhanced the documentation of the project:

* https://github.com/Rudd-O/qubes-network-server
*
https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20your%20first%20server.md
*
https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20an%20SSH%20server.md

This project is now ready and documented enough to be useful to users of
Ansible Qubes who want to remotely manage clusters of Qubes OS machines:

*
https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Remote%20management%20of%20Qubes%20OS%20servers.md
*
https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Enhance%20your%20Ansible%20with%20Ansible%20Qubes.md

I strongly welcome anyone who tries this and shares their experiences.
It is my goal to get this to be a key part of the Qubes OS strategy.

--

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

[Max]

For the "make rpm" command you refer to the local directory of your clone, is there a tutorial you recommend I should follow for doing this?

Thank you

[Manuel Amador (Rudd-O)]

That *is* the tutorial. cd into your clone, then type "make rpm"
(without the quotes).

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

[Max]

I have tried that but I get the following error - any idea what this means?

[user@my-new-vm qubes-network-server]$ sudo make rpm
find -name '*.pyc' -o -name '*~' -print0 | xargs -0 rm -f
rm -f *.tar.gz *.rpm
DIR=qubes-network-server-`awk '/^Version:/ {print $2}' qubes-network-server.spec` && FILENAME=$DIR.tar.gz && tar cvzf "$FILENAME" --exclude "$FILENAME" --exclude .git --exclude .gitignore -X .gitignore --transform="s|^|$DIR/|" --show-transformed *
qubes-network-server-0.0.4/doc/
qubes-network-server-0.0.4/doc/Setting up an SSH server.md
qubes-network-server-0.0.4/doc/Standard Qubes OS network model.png
qubes-network-server-0.0.4/doc/Qubes network server model.dia
qubes-network-server-0.0.4/doc/Standard Qubes OS network model.dia
qubes-network-server-0.0.4/doc/Qubes network server model.png
qubes-network-server-0.0.4/doc/Setting up your first server.md
qubes-network-server-0.0.4/Makefile
qubes-network-server-0.0.4/qubes-network-server.spec
qubes-network-server-0.0.4/README.md
qubes-network-server-0.0.4/src/
qubes-network-server-0.0.4/src/usr/
qubes-network-server-0.0.4/src/usr/bin/
qubes-network-server-0.0.4/src/usr/bin/qvm-static-ip
qubes-network-server-0.0.4/src/usr/lib64/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/007FortressQubesProxyVm.py
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/006FortressQubesNetVm.py
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/001FortressQubesVm.py
qubes-network-server-0.0.4/TODO
T=`mktemp -d` && rpmbuild --define "_topdir $T" -ta qubes-network-server-`awk '/^Version:/ {print $2}' qubes-network-server.spec`.tar.gz || { rm -rf "$T"; exit 1; } && mv "$T"/RPMS/*/* "$T"/SRPMS/* . || { rm -rf "$T"; exit 1; } && rm -rf "$T"
/bin/sh: rpmbuild: command not found
Makefile:13: recipe for target 'rpm' failed
make: *** [rpm] Error 1

[cyrinux]

Hi,
run 'sudo dnf install rpm-build' and try again, you don't have rpm tools

[Max]

Thanks for the response!

I ran this and also ran 'sudo dnf install go' when I came across the following error: 'go is needed by qubes-network-server-0.0.4-1.fc23.noarch'.

I then did the cd into the cloned folder and the 'make rpm' function has appeared to have worked.

I followed the steps to get this to Dom0 and then installed the RPM. It may be better to add to the documentation 'sudo rpm -ivh qns.rpm' as I wasn't initially sure that I actually had to name the file. It helps the noobs!

The purpose for me for installing the network server was to be able to ping my Debian VM from my Windows VM.

These are the configuration steps I took subsequent to install:

1) Created a ProxyVM named server-proxy.
2) Changed the NetVM on both work-apps (my Debian 8 VM) and windows-7 (HVM) to the new ProxyVM
3) Set the static IP addresses using the following commands in Dom0 terminal: qvm-static-ip -s work-apps static_ip 192.137.4.18 and then qvm-static-ip -s windows-7 static_ip 192.137.4.19 which were the same IP addresses they were dynamically assigned.
4) Restarted my work-apps (Debian 8 VM)
5) Set the firewall rules on my work-apps (Debian 8 VM) in the VM Manager to be from-192.137.4.19, selected the TCP protocol, put 80 on the Service box and then saved.

I then tried to ping the work-apps (Debian 8 VM) from the Windows 7 HVM but just got Destination host unreachable responses.

Any ideas how to solve this issue? Many thanks.

[Manuel Amador (Rudd-O)]

On 11/05/2016 03:54 PM, Max wrote:
>
> Thanks for the response!
>
> I ran this and also ran 'sudo dnf install go' when I came across the following error: 'go is needed by qubes-network-server-0.0.4-1.fc23.noarch'.

A commit is now out which eliminates this dependency.

> I then did the cd into the cloned folder and the 'make rpm' function has appeared to have worked.
>
> I followed the steps to get this to Dom0 and then installed the RPM. It may be better to add to the documentation 'sudo rpm -ivh qns.rpm' as I wasn't initially sure that I actually had to name the file. It helps the noobs!
>
> The purpose for me for installing the network server was to be able to ping my Debian VM from my Windows VM.
>
> These are the configuration steps I took subsequent to install:
>
> 1) Created a ProxyVM named server-proxy.
> 2) Changed the NetVM on both work-apps (my Debian 8 VM) and windows-7 (HVM) to the new ProxyVM

Sorry, I should have clarified that HVMs are not supported at all. I am
very, very sorry. I need to do more work to get HVMs to work properly
("more" is an euphemism for I have totally forgotten so far to support
that use case). It is totally my fault that I did not explain this in
the documentation. My bad. I have updated the documentation to reflect
that.

If you could help me, do report what happens when you ping between a
Fedora and a Debian AppVM, or two Debian AppVMs.

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

[Max]

> Sorry, I should have clarified that HVMs are not supported at all. I am
> very, very sorry. I need to do more work to get HVMs to work properly
> ("more" is an euphemism for I have totally forgotten so far to support
> that use case). It is totally my fault that I did not explain this in
> the documentation. My bad. I have updated the documentation to reflect
> that.

:( Thanks for the quick notice to let me know. Also, well done for getting this developed anyway. It is an excellent contribution.

It would be a really big help if you were able to enhance this capability in the future. The benefits of virtualisation in Qubes is well understood from an isolation perspective but one other reason to use virtualisation is, of course, to run programs concurrently that cannot be run in a single OS. I unfortunately need to run Windows as I have specific software that doesn't run on Linux. I would like to keep all my programs in a single Debian or Fedora VM but I am being forced to work with Windows so my plan was to keep as much software out of this environment as possible.

> If you could help me, do report what happens when you ping between a
> Fedora and a Debian AppVM, or two Debian AppVMs.

This worked first time!

I pinged from the Debian AppVM to a new Fedora AppVM. I checked that the pinging did not work first and then went through the steps to change the Fedora AppVM to connect to the proxy server NetVM, assign a static IP, restart, set the firewall rules and then ping.

In the meantime, could I ask if it is possible to do what I am trying to achieve by adjusting the iptables? I reported my troubles attempting to do this here: https://groups.google.com/d/msg/qubes-users/Dan7LNLv048/pkT_O2tDAAAJ

[Manuel Amador (Rudd-O)]

On 11/07/2016 02:29 PM, Max wrote:
>
> This worked first time!
>
> I pinged from the Debian AppVM to a new Fedora AppVM. I checked that the pinging did not work first and then went through the steps to change the Fedora AppVM to connect to the proxy server NetVM, assign a static IP, restart, set the firewall rules and then ping.
>
> In the meantime, could I ask if it is possible to do what I am trying to achieve by adjusting the iptables? I reported my troubles attempting to do this here: https://groups.google.com/d/msg/qubes-users/Dan7LNLv048/pkT_O2tDAAAJ

It's not clear to me what you are trying to achieve. Can you describe
it in English with examples?


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

[Max]

> It's not clear to me what you are trying to achieve. Can you describe
> it in English with examples?
>
>
> --
> Rudd-O
> http://rudd-o.com/

I am trying to ping a Debian PVM from a Windows HVM. This requirement is due to the fact that I am running a program in Windows that is not supported in Debian or Fedora yet it needs to be connected to my database in Debian.

When following the instructions for amending the iptables rules amendment here: https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes, I found that this only worked for connecting from a PVM to a PVM i.e. Fedora to Debian but not from HVM to PVM i.e. Windows to Debian.

I wanted to confirm if this was possible and to understand what is required to get this working.

[Joonas Lehtonen]

Hi,

before trying it:
Is it still maintained? (working with Qubes 3.2)

If so: There are a few formatting errors in the readme that make it hard
to read
https://github.com/Rudd-O/qubes-network-server/blob/master/README.md

thanks,
Joonas

[Thierry Laurion]

Considering Qubes 4.x has switched to HVM, what needs to be done to support this mode of operation?
Opened a ticket to track this issue: https://github.com/Rudd-O/qubes-network-server/issues/4

[Manuel Amador (Rudd-O)]

On 10/09/2017 04:49 PM, Thierry Laurion wrote:
>
> Considering Qubes 4.x has switched to HVM, what needs to be done to support this mode of operation?
> Opened a ticket to track this issue: https://github.com/Rudd-O/qubes-network-server/issues/4
>

Thank you for opening the ticket.  It may be difficult for me to adapt
to 4.0, so I kindly request anyone with the required skillset to send a
pull request adapting it to 4.0.

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