Project update

Readme.md

@@ -13,6 +13,8 @@ First develop and document the part related to manual port forwarding since it i
  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
+ 4. https://github.com/QubesOS/qubes-issues/issues/5031
+ 5. https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248
 
 ## Development
 ### Background
@@ -23,10 +25,11 @@ First develop and document the part related to manual port forwarding since it i
  * https://www.qubes-os.org/doc/config-files/
 
 ### Dev Repositories
- * https://git.lsd.cat/Qubes/core-admin
- * https://git.lsd.cat/Qubes/core-admin-client
- * https://git.lsd.cat/Qubes/core-agent-linux
+ * https://github.com/lsd-cat/qubes-core-admin
+ * https://github.com/lsd-cat/qubes-core-admin-client
+ * https://github.com/lsd-cat/qubes-core-agent-linux
 
+All changes are in the `gsoc-port-forwarding` branch of each repo.
 
 ### Main components involved
  1. [Firewall GUI in "Settings" (qubes-manager)](https://github.com/QubesOS/qubes-manager/blob/master/qubesmanager/firewall.py)
@@ -133,7 +136,9 @@ Of course `expire=` and `comment=` are optional fields.
 				<property name="comment">example https server rule</property>
 			</properties>
 		</rule>
-```
+```Sorry. We’re having trouble getting your pages back.
+
+We are having trouble restoring your last browsing session. Select Restore Session to try again.
 
 ### Proposal chart
 ###### The main distinction between internal and external port forwarding is:
@@ -165,53 +170,86 @@ options as the point above
 here. Here there is the need to resolve the full network chain for
 external port forwarding. From here it is possible to add the respective
 rules to the QubesDB of each NetVM in he chain and trigger a reload event.
- 4. 🚧 In `core-agent-linux/qubesagent/firewall.py` -> Here goes the logic for
+ 4. ✔️ In `core-agent-linux/qubesagent/firewall.py` -> Here goes the logic for
 building the correct syntax for iptables or nft and the actual execution
- 5. ❌ GUI
- 6. ❌ Tests
+ 5. ❌ Tests
+ 6. ❌ GUI
 
+ Both tests and GUI have yet to be worked on. Automated tests will be written soon in the following weeks.
 
 ### Required rules
 #### External
+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.
 
-***srchost and srcports support yet to be written here ***
-In `<networkvm>`:
+Sample setup:
 
 ```
-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
+sys-net - 10.137.0.5 (ens6 phy with 192.168.10.20)
+sys-firewall - 10.137.0.6
+personal - 10.137.0.7
 ```
 
-In `<firewallvm>`:
+All of them are running fedora-32.
 
-```
-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
+And assume the following rule added via qvm-firewall:
+
+```# qvm-firewall personal add action=forward forwardtype=external scrports=22-22 proto=tcp dstports=2222-2222 srchost=192.168.10.0/24
 ```
 
-in `<appvm>`:
+First, a table for the forwarding rules is created:
+
 ```
-iptables -w -I INPUT 5 -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT
+flush chain {family} qubes-firewall-forward prerouting
+flush chain {family} qubes-firewall-forward postrouting
+table {family} qubes-firewall-forward {
+    chain postrouting {
+        type nat hook postrouting priority srcnat; policy accept;
+        masquerade
+    }
+    chain prerouting {
+        type nat hook prerouting priority dstnat; policy accept;
+        }
+}
 ```
 
-#### Internal
-In `<firewallvm>`:
+Then, if the qube is marked as 'last', meaning that it is the external qube with the physical interface the following rules are added:
 
 ```
-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
+table {family} qubes-firewall-forward {
+    chain prerouting {
+        meta iifname "ens6" {family} saddr 192.168.10.0/24 tcp dport {{ 22 }} dnat to 10.137.0.6:2222
+    }
+}
+
+table {family} qubes-firewall {
+    chain forward {
+        meta iifname "eth0" {family} daddr 10.137.0.6 tcp dport 2222 ct state new counter accept
+    }
+}
 ```
 
-in `<appvm>`:
+And that is all for sys-net.
+
+In sys-firewall, since it is an 'internal' qube, the following rules are added instead:
+
 ```
-iptables -w -I INPUT 5 -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT
+table {family} qubes-firewall-forward {
+    chain prerouting {
+        meta iifname "eth0" {family} saddr 120.137.0.5 tcp dport {{ 2222 }} dnat to 10.137.0.7:2222
+    }
+}
+
+table {family} qubes-firewall {
+    chain forward {
+        meta iifname "eth0" {family} daddr 10.137.0.7 tcp dport 2222 ct state new counter accept
+    }
+} 
 ```
 
+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.
+
 ## Extra
-### QubedDB Debugging
+### QubesDB Debugging
 
 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: