Second draft

Readme.md

@@ -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
+```