The Qubes codebase is complex but well organized and written. Simple tasks, such as the basic port forwarding do require to edit and commit to multiple different components of the ecosystem. As a new entry, a lot has to be learned before being able to understand the whole picture and thus being able to plan new fetures and write useful code. Furthermore, setting up a testing environment has proven to be somewhat hard and testing is anyway is currently a manual process and is a bit time consuming.
In this page. The original goals of this GSOC had to be scaled down in impelementing simple and straightforward port forwarding of two types via CLI only.
This page also contains the notes i took during the planning and development process.
Forwarding ports to Qubes VM is currently possible only though a multi step, error prone, manual process that also requires writing custom configuration in order to be persistent between reboots. Things as simple as starting a webserver or netcat for LAN file sharing canbe eventually a troublesome and time-wasting process[1][2]. Furthermore, applications thatrely on NAT traversal protocols such as those for audio and video communications do not workin direct P2P mode with STUN and always use TURN instead[3].
Implement a GUI for automatic and persistent, eventually with a predefined timespan (ie: untilreboot), port forwarding. The idea is to split horizontally the "Firewall Rules" tab in the"Qubes Settings" window and add another area below it. It is already possible to forward TCP streams, however there is no GUI nor a clear dashboard and furthermore its versatility is limited. In addition, discuss and verify the possibility to implement a secure NAT traversal systemand GUI. A basic proposal could be a checkbox to enable NAT traversal requests. When the checkbox is selected, the FirwallVM will redirect NAT traversal requests to a local pythondaemon or a dedicated VM that will negotiate the NAT traversal and configure the networkaccordingly. In this case, prompt the user in Dom0 about the NAT traversal request. Of coursethe qvm-* set of tools must e able to achieve the same tasks via CLI.
First develop and document the part related to manual port forwarding since it is both a more frequent use case and is less complicated. Depending on the problems encountered, evaluate the feasibility of secure NAT traversal.
1. [Firewall GUI in "Settings" (qubes-manager)](https://github.com/QubesOS/qubes-manager/blob/master/qubesmanager/firewall.py)
2. [CLI interface available via `qvm-firewall` (core-admin-client)](https://github.com/QubesOS/qubes-core-admin-client/blob/master/qubesadmin/tools/qvm_firewall.py)
3. [Actual client logic for the Admin API (core-admin-client)](https://github.com/QubesOS/qubes-core-admin-client/blob/master/qubesadmin/firewall.py)
4. [Admin API interface - XML conf manager (core-admin)](https://github.com/QubesOS/qubes-core-admin/blob/master/qubes/firewall.py)
5. [Agent running in firewall vm - executes `nft` or `iptables`](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubesagent/firewall.py)
### Current Status
#### How does the GUI and `qvm-firewall` configuration work?
The Qubes Manager GUI and the `qvm-firewall` both use the code imlemented in the Admi API Client library. The Client Library sends specific messages to the `qubesd` daemon.
The currently supported operatins are:
*`admin.vm.firewall.Get`
*`admin.vm.firewall.Set`
*`admin.vm.firewall.Reload`
These actions can be tested by using the `qvm-firewall` utility. It is important to note that both the client and the daemon are more flexibile compared to the settings available via the GUI.
##### Configuration files
If any non default configuration is set by the user, an AppVM will have a `firewall.xml` configuration file in the `var/lib/qubes/<appvm>/` path. Deleting the file will reset the firewall to the default state and any customization will be lost.
The `firewall.xml` is clearly human readable and contains rules in the form:
```
<firewallversion="2">
<rules>
<rule>
<properties>
<!-- accept outgoing to lsd.cat porto tcp port 443 -->
<propertyname="action">accept</property>
<propertyname="dsthost">lsd.cat</property>
<propertyname="proto">tcp</property>
<propertyname="dstports">443</property>
</properties>
</rule>
<rule>
<properties>
<!-- accept outgoing to 10.132.11.1/24 proto any -->
<propertyname="action">accept</property>
<propertyname="dsthost">10.132.11.1/24</property>
</properties>
</rule>
<rule>
<properties>
<!-- allow outgoing dns queries. needed for domain based rules -->
<propertyname="action">accept</property>
<propertyname="specialtarget">dns</property>
</properties>
</rule>
<rule>
<properties>
<!-- drop everything else -->
<propertyname="action">drop</property>
</properties>
</rule>
</rules>
</firewall>
```
##### Commands
The following command will return the firewall rules for `<vmnname>`.
```
qvm-firewall <vmname>
```
As can be seen, the output will show more colums that the GUI, specifically an `EXPIRE`, `COMMENT`, and `SPECIAL TARGET` columns will be displayed.
The following command will reload the persistent rules stored in `firewall.xml` of `<vmname>`
```
qvm-firewall <vmname> --reload
```
The following command can be used to add a rule. Not that if the GUI detects that the firewall has been edited from CLI, since it does not support all CLI settings, it will refuse to allow management again from the GUI.
Currently, all firewall rules have an `action` properties which can be either `accept` or `drop`. The plan is to add a third option `forward` specifically for implementing automatic port forwarding. Such options must be supported both in the configuration file and in the Admin API (client-server). Lastly, it shall be implemented in the agent daemon.
The main issue however is the fact that currenly, the firewall client library is designated to operate only on the AppVM configured Firewall NetVM. However, in order to forward ports from the outside world, specific rules needs to be applied to the Firewall NetVM Networking NetVM. (ie: both is `sys-firewall` and `sys-net`, as currently done for manual port forwarding).
### action=forward
Since in the case of port forwarding the target ip address would always be the `<vmname>` IP address, users should not be asked for a `dsthost` field. Adding a forward rule could look like this:
Steps 1-3 are completed and needs the automated test. Step 4 has still some issues but it is in its final stages. 5 will be worked on in the following weeks, since it is mandatory before merging anything. 6 can come at a later stage.
The iptables backend in the firewall worker is being deprecated. If the `nft` binary is available on the target Qubes, iptables will be never involved. Thus, only `nft` rules are relevant in this context.
Lastly, some rules need to be added in the target Qube in order to accept the incoming connections. Since the target Qube does not have a running firewall worker, the method for doing this has yet to be determined.
Since all firewall rules are written to the respective domains QubesDB by the `qubesd` it is essential dor debugging purposes to be able to easily read QubesDB entries. The QubesOS Project provide some useful utilities to interact with each DB. Such utilities have self explicative names and works like the respective functions used in the source code. The most useful are:
* Add `sys-net` SSH pubkey on Windows for non interactive authentication (`sshd` is easier using Windows Subsystem for Linux)
* Via scp/sftp, copy all the bash script in the `sys-net` VM. Leve `pull.sh` in `/home/user/pull.sh`
* Using `qvm-run` copy `backup.sh`, `restore.sh` and `updte.sh` in `Dom0`
* First, run once `backup.sh` and pay attention to never run it again in order to recover from broken states (breaking qubesd, `qvm-run` will stop working and it will be hard to recover)
* Run `update.sh` to automatically pull changes from the Windows host. `qubesd` is restarted within the same script.
* In case of issues, run `restore.sh` and investigate the previous errors
