Qubes/gsoc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Second draft

Browse Source
This commit is contained in:
Giulio 2021-06-22 01:26:24 +02:00
parent a1de48a081
commit 4dba793a82
1 changed files with 50 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
Readme.md
View File

@ -10,9 +10,9 @@ Implement a GUI for automatic and persistent, eventually with a predefined times
First develop and document the part related to manual port forwarding since it is both a morefrequent use case and is less complicated. Depending on the problems encountered, evaluate thefeasibility of secure NAT traversal.
#### Notes
[1] - https://github.com/QubesOS/qubes-issues/issues/3556
[2] -https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/
[3] - https://github.com/QubesOS/qubes-issues/issues/6225
1. https://github.com/QubesOS/qubes-issues/issues/3556
2. https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/
3. https://github.com/QubesOS/qubes-issues/issues/6225
## Development
### Background
@ -96,6 +96,52 @@ 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.
```
qvm-firewall <vmname> add action=accept dsthost=1.1.1.1 proto=tcp command="cloudflare http test rule" expire=+5000
qvm-firewall <vmname> add action=accept dsthost=1.1.1.1 proto=tcp dstports=80-80 command="cloudflare http test rule" expire=+5000
```
### Proposal
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. Sych options must be supported both in the configuration file and in the Sdmin 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:
```
qvm-firewall <vmname> add action=forward proto=tcp dstports=443-443 command="example https server rule" expire=+500000
```
Of course `expire=` and `comment=` are not optional fields.
```
<rule>
<properties>
<!-- sample syntax for port forwarding -->
<property name="action">forward</property>
<property name="proto">tcp</property>
<property name="dstports">443</property>
</properties>
</rule>
```
### Required rules
In `<networkvm>`:
```
iptables -t nat -A PREROUTING -i <external_iinterface> -p tcp --dport <target_port> -d <interface_ip> -j DNAT --to-destination <firewallvm_ip>
iptables -I FORWARD 2 -i <external_iinterface> -d <firewallvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT
nft add rule ip qubes-firewall forward meta iifname <external_iinterface> ip daddr <firewallvm_ip> tcp dport <target_port> ct state new counter accept
```
In `<firewallvm>`:
```
iptables -t nat -A PREROUTING -i <interface> -p tcp --dport <target_port> -d <firewallvm_ip> -j DNAT --to-destination <appvm_ip>
iptables -I FORWARD 2 -i <interface> -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT
nft add rule ip qubes-firewall forward meta iifname <interface> ip daddr <appvm_ip> tcp dport <target_port> ct state new counter accept
```
in `<appvm>`:
```
iptables -w -I INPUT 5 -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT
```