|
|
@@ -108,8 +108,8 @@ The main issue however is the fact that currenly, the firewall client library is
|
|
|
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 type=external srcports=443-443 dstports=80443-80443 srchost=0.0.0.0/0 expire=+500000 comment="example https server rule"
|
|
|
-qvm-firewall <vmname> add action=forward proto=tcp type=internal srcports=80-80 dstports=8000-8000 srchost=10.137.0.13 expire=+500000 comment="example internal simplehttpserver file sharing rule"
|
|
|
+qvm-firewall <vmname> add action=forward proto=tcp forwardtype=external srcports=443-443 dstports=80443-80443 srchost=0.0.0.0/0 expire=+500000 comment="example https server rule"
|
|
|
+qvm-firewall <vmname> add action=forward proto=tcp forwardtype=internal srcports=80-80 dstports=8000-8000 srchost=10.137.0.13 expire=+500000 comment="example internal simplehttpserver file sharing rule"
|
|
|
```
|
|
|
|
|
|
Of course `expire=` and `comment=` are optional fields.
|
|
|
@@ -120,7 +120,7 @@ Of course `expire=` and `comment=` are optional fields.
|
|
|
<!-- sample syntax for port forwarding -->
|
|
|
<property name="action">forward</property>
|
|
|
<property name="proto">tcp</property>
|
|
|
- <property name="type">external</property>
|
|
|
+ <property name="forwardtype">external</property>
|
|
|
<property name="srcports">443-443</property>
|
|
|
<property name="dstports">80443-80443</property>
|
|
|
<property name="srchost">0.0.0.0/0</property>
|
|
|
@@ -130,8 +130,25 @@ Of course `expire=` and `comment=` are optional fields.
|
|
|
```
|
|
|
|
|
|
### Proposal chart
|
|
|
+The main distinction between internal and external port forwarding is:
|
|
|
+
|
|
|
+ * _Internal_ resolves only <appvm>'s <ntvm>
|
|
|
+ * _External_ recursively resolves all upstream networking vm and sets forwarding rules on all of them
|
|
|
+
|
|
|
+This should cover multiple scenarios:
|
|
|
+ * _Standard external forwarding_ when <appvm> service needs to be exposed on a physical interface
|
|
|
+ * _Standard internal forwarding_ when <appvm> service needs to be exposed to other <appvm2/3/4> connected to the same <netvm>
|
|
|
+ * _VPN internal port forwarding_ when <appvm> service needs to be exposed through a VPN
|
|
|
+
|
|
|
+It is important to note that in the last case, it is just a standard case of internal forwarding.
|
|
|
+
|
|
|
+
|
|
|
|
|
|
|
|
|
+#### Implementation roadmap
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
### Required rules
|
|
|
|
|
|
#### External
|
