20210622-Re_GSoC Port Forwarding-13697.html 29 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395
  1. <html>
  2. <head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  3. <title>Re: GSoC Port Forwarding</title>
  4. <link rel="important stylesheet" href="">
  5. <style>div.headerdisplayname {font-weight:bold;}
  6. </style></head>
  7. <body>
  8. <table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><div class="headerdisplayname" style="display:inline;">Oggetto: </div>Re: GSoC Port Forwarding</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Mittente: </div>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>22/06/2021, 16:04</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><div class="headerdisplayname" style="display:inline;">A: </div>Giulio <giulio@gmx.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
  9. <div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
  10. On Tue, Jun 22, 2021 at 02:28:26PM +0200, Giulio wrote:
  11. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  12. <span class="moz-txt-citetags">&gt; </span>Hello,
  13. <span class="moz-txt-citetags">&gt; </span>thank you for the detailed response.
  14. <span class="moz-txt-citetags">&gt; </span>
  15. <span class="moz-txt-citetags">&gt; </span>Il 22/06/2021 04:43, Marek Marczykowski-Górecki ha scritto:
  16. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  17. <span class="moz-txt-citetags">&gt; &gt; </span>Hi, I'm replying to both emails at once:
  18. <span class="moz-txt-citetags">&gt; &gt; </span>
  19. <span class="moz-txt-citetags">&gt; &gt; </span>On Sun, Jun 20, 2021 at 10:50:04PM +0200, Giulio wrote:
  20. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  21. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>Questions:
  22. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>
  23. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>1) Should we both support internal port forwarding and external port
  24. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>forwarding? Such as exposing a port for another domain or exposing a
  25. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>port through the public network interface? I would say yes.
  26. </pre></blockquote><pre wrap class="moz-quote-pre">
  27. <span class="moz-txt-citetags">&gt; &gt; </span>
  28. <span class="moz-txt-citetags">&gt; &gt; </span>Yes, I think so. Technically, those two cases should be quite similar.
  29. <span class="moz-txt-citetags">&gt; &gt; </span>See also the case of sys-vpn much lower in the email.
  30. <span class="moz-txt-citetags">&gt; &gt; </span>
  31. </pre></blockquote><pre wrap class="moz-quote-pre">
  32. <span class="moz-txt-citetags">&gt; </span>
  33. <span class="moz-txt-citetags">&gt; </span>I think that I'm actually failing to picture all the possible internal
  34. <span class="moz-txt-citetags">&gt; </span>scenarios.
  35. <span class="moz-txt-citetags">&gt; </span>
  36. <span class="moz-txt-citetags">&gt; </span>1) In the case of external port forwarding &lt;sys-net&gt; should forward to
  37. <span class="moz-txt-citetags">&gt; </span>&lt;sys-firewall&gt; and &lt;sys-firewall&gt; then to the &lt;appvm&gt;.
  38. <span class="moz-txt-citetags">&gt; </span>In this case the port gets forwarded on the external interface ie: a LAN
  39. <span class="moz-txt-citetags">&gt; </span>or a public ip address depending on the network environment.
  40. </pre></blockquote><pre wrap class="moz-quote-pre">
  41. Yes.
  42. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  43. <span class="moz-txt-citetags">&gt; </span>2) In the case of internal port forwarding, the port is forwarded only
  44. <span class="moz-txt-citetags">&gt; </span>from &lt;sys-firewall&gt; to &lt;appvm&gt;. In that case, another &lt;appvm2&gt; can visit
  45. <span class="moz-txt-citetags">&gt; </span>the &lt;appvm&gt; service using &lt;sys-firewall&gt; ip address and the chosen port.
  46. </pre></blockquote><pre wrap class="moz-quote-pre">
  47. Yes.
  48. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  49. <span class="moz-txt-citetags">&gt; </span>In this case, the ports get exposed on &lt;sys-firewall&gt; and thus depending
  50. <span class="moz-txt-citetags">&gt; </span>on how the rules are implemented, may be available to all the AppVMs
  51. <span class="moz-txt-citetags">&gt; </span>that share the same &lt;sys-firewall&gt;.
  52. </pre></blockquote><pre wrap class="moz-quote-pre">
  53. Yes.
  54. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  55. <span class="moz-txt-citetags">&gt; </span>In both cases may be important to allow to specify access rules for the
  56. <span class="moz-txt-citetags">&gt; </span>forwarded port, such as the lan/public ip addresses ranges allowed for
  57. <span class="moz-txt-citetags">&gt; </span>case 1 and the appvm name for case 2.
  58. </pre></blockquote><pre wrap class="moz-quote-pre">
  59. Yes, indeed.
  60. </pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  61. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>3) Since the expire= feature seems to be already implemented (and
  62. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>limited for the expiring full outgoing access) would it be useful to be
  63. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>implemented in gui and cli for every rule? I would say yes since the
  64. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>admin and agent code seems to be already there. The same goes for the
  65. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>"comment=" field.
  66. </pre></blockquote><pre wrap class="moz-quote-pre">
  67. <span class="moz-txt-citetags">&gt; &gt; </span>
  68. <span class="moz-txt-citetags">&gt; &gt; </span>Per-rule expire may be tricky to handle at the GUI level, I have no idea
  69. <span class="moz-txt-citetags">&gt; &gt; </span>how to make the UI for this not very confusing...
  70. <span class="moz-txt-citetags">&gt; &gt; </span>But the comment field is definitely useful to use.
  71. <span class="moz-txt-citetags">&gt; &gt; </span>
  72. </pre></blockquote><pre wrap class="moz-quote-pre">
  73. <span class="moz-txt-citetags">&gt; </span>
  74. <span class="moz-txt-citetags">&gt; </span>How do you see the same checkbox that actually allows full internet
  75. <span class="moz-txt-citetags">&gt; </span>access with the 5 minutes expiration time, displayed also on the window
  76. <span class="moz-txt-citetags">&gt; </span>for adding a rule?
  77. </pre></blockquote><pre wrap class="moz-quote-pre">
  78. This may be more relevant to longer times. With times like 5min, just
  79. setting the rules up (if you want more than one of them) may already eat
  80. up significant portion of the expiration time...
  81. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  82. <span class="moz-txt-citetags">&gt; </span>However I think there is time to think more through this as the UI will
  83. <span class="moz-txt-citetags">&gt; </span>be the last component.
  84. <span class="moz-txt-citetags">&gt; </span>
  85. </pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  86. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>4) How would you implement the management of forwarding rules in the
  87. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>network providing domain (sys-net)? Shall the user add a rule both in
  88. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>the target domain (ie the one with webserver and another one in sys-net)
  89. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>or should it be fully automatic from the first?
  90. </pre></blockquote><pre wrap class="moz-quote-pre">
  91. <span class="moz-txt-citetags">&gt; &gt; </span>
  92. <span class="moz-txt-citetags">&gt; &gt; </span>From the user point of view, I think it should be automated as much as
  93. <span class="moz-txt-citetags">&gt; &gt; </span>possible. Like, let the user choose which port in which VM redirect to
  94. <span class="moz-txt-citetags">&gt; &gt; </span>where. There may be cases when such redirection won't be possible - if
  95. <span class="moz-txt-citetags">&gt; &gt; </span>there is no network path between the two points.
  96. <span class="moz-txt-citetags">&gt; &gt; </span>
  97. </pre></blockquote><pre wrap class="moz-quote-pre">
  98. <span class="moz-txt-citetags">&gt; </span>
  99. <span class="moz-txt-citetags">&gt; </span>I agree with you. We might just check when the user adds an internal
  100. <span class="moz-txt-citetags">&gt; </span>forwarding rule if both the source and the destination shares the same
  101. <span class="moz-txt-citetags">&gt; </span>&lt;firewallvm&gt;, don't we?
  102. </pre></blockquote><pre wrap class="moz-quote-pre">
  103. I think we can simplify it even further: allow forwarding ports only
  104. from (any of) upstream VMs. For example in this case:
  105. appvm1 -&gt; sys-firewall -&gt; sys-net
  106. | |
  107. appvm2 ------+ |
  108. |
  109. appvm3 -&gt; some-other-firewall -+
  110. Allow forwarding to appvm1 only from sys-net (external case) or
  111. sys-firwall, but not appvm3 or some-other-firewall.
  112. Then, within the forward rule configuration you can restrict access
  113. rules (like you propose below, with default 0.0.0.0/0). This restriction
  114. will work for VMs directly connected to sys-firewall only, because there
  115. is NAT (sys-net does not know whether its appvm1 or appvm2 - it only
  116. sees sys-firewall IP in those cases). But I think it's ok to make this
  117. limitation and require VMs to be connected to the same &lt;firewallvm&gt; if
  118. you want to forward traffic between them.
  119. I think you did it right with the internal/external type.
  120. Allowing forwarding from others (like some-other-firewall in the picture
  121. above) may be tricky (and unreliable), as it will be hard to restrict
  122. who can really connect (sys-net have no idea which VM behind
  123. sys-firewall/some-other-firewall really connects).
  124. </pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  125. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>5) Users should be able to set forward rules using domain names and not
  126. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>static ip addresses. In this case, the actual ip addresses of the dst
  127. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>domains should be collected in a similr way as currently DNS are
  128. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
  129. </pre></blockquote><pre wrap class="moz-quote-pre">
  130. <span class="moz-txt-citetags">&gt; &gt; </span>
  131. <span class="moz-txt-citetags">&gt; &gt; </span>But here we are mostly talking about IP addresses of different VMs,
  132. <span class="moz-txt-citetags">&gt; &gt; </span>right? Those can (and should) be resolved at core-admin side, so the VM
  133. <span class="moz-txt-citetags">&gt; &gt; </span>applying the rules will have all the IP given. In fact VM may not be
  134. <span class="moz-txt-citetags">&gt; &gt; </span>able to resolve IP of another VM at all.
  135. <span class="moz-txt-citetags">&gt; &gt; </span>
  136. </pre></blockquote><pre wrap class="moz-quote-pre">
  137. <span class="moz-txt-citetags">&gt; </span>
  138. <span class="moz-txt-citetags">&gt; </span>Thanks for the insight, it totally makes sense.
  139. <span class="moz-txt-citetags">&gt; </span>
  140. </pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  141. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>Proposed XML Syntax:
  142. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>&lt;rule&gt;
  143. <span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;properties&gt;
  144. <span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;property name="action"&gt;forward&lt;/property&gt;
  145. <span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;property name="proto"&gt;udp&lt;/property&gt;
  146. <span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
  147. <span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;/properties&gt;
  148. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>&lt;rule&gt;
  149. </pre></blockquote><pre wrap class="moz-quote-pre">
  150. <span class="moz-txt-citetags">&gt; &gt; </span>
  151. <span class="moz-txt-citetags">&gt; &gt; </span>I don't see an important information here: forward to <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>where<span class="moz-txt-tag">_</span></span>.
  152. <span class="moz-txt-citetags">&gt; &gt; </span>
  153. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  154. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>Proposed Admin API Syntax:
  155. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
  156. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>timestamp&gt;] [comment=random text]
  157. </pre></blockquote><pre wrap class="moz-quote-pre">
  158. <span class="moz-txt-citetags">&gt; &gt; </span>
  159. <span class="moz-txt-citetags">&gt; &gt; </span>Similar here, there needs to be a forward target (IP, and possibly a
  160. <span class="moz-txt-citetags">&gt; &gt; </span>port)
  161. <span class="moz-txt-citetags">&gt; &gt; </span>
  162. <span class="moz-txt-citetags">&gt; &gt; </span>On Tue, Jun 22, 2021 at 01:49:15AM +0200, Giulio wrote:
  163. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  164. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>Since in the case of port forwarding the target ip address would always be the &lt;vmname&gt; IP address,
  165. </pre></blockquote><pre wrap class="moz-quote-pre">
  166. <span class="moz-txt-citetags">&gt; &gt; </span>
  167. <span class="moz-txt-citetags">&gt; &gt; </span>This is very true. But there needs to be an information where to forward
  168. <span class="moz-txt-citetags">&gt; &gt; </span>the traffic to (as noted earlier). Plus, possibly a second set of ports
  169. <span class="moz-txt-citetags">&gt; &gt; </span>(if you want to redirect to a different port).
  170. <span class="moz-txt-citetags">&gt; &gt; </span>
  171. </pre></blockquote><pre wrap class="moz-quote-pre">
  172. <span class="moz-txt-citetags">&gt; </span>
  173. <span class="moz-txt-citetags">&gt; </span>I am still failing to understand something here, could you give me a an
  174. <span class="moz-txt-citetags">&gt; </span>example on when the dsthosts would different rather than the &lt;appvm&gt; or
  175. <span class="moz-txt-citetags">&gt; </span>&lt;firewallvm&gt; ip?
  176. </pre></blockquote><pre wrap class="moz-quote-pre">
  177. I'm talking about the other end of the connection. Let me summarize
  178. this for different rules:
  179. 1. For allow/deny rules, it is about where the VM can connect to -
  180. outgoing connection. The source IP is always the VM's IP (implicitly),
  181. and the rule can specify destination IP, protocol, port.
  182. 2. For forward rules, it is about incoming connection - the destination
  183. IP is VM's IP (implicitly), but then the connection is redirected to
  184. somewhere else (like some appvm) - and the rule needs to point out to
  185. where it should redirect.
  186. If you have simplified case like this:
  187. sys-net -&gt; appvm
  188. Then, the rule in sys-net not only needs to know what to redirect (like,
  189. TCP port 80), but also needs to know to redirect it to appvm, not
  190. anywhere else.
  191. Similarly, if the rule is stored with appvm, it needs to know to
  192. install the redirect in sys-net and not some intermediate other VM (as
  193. talked about internal, or VPN or Tor cases).
  194. Ok, reading your response further, I think you covered it with
  195. external/internal type, so it should be good.
  196. </pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  197. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>I think my main concern now is the question 4 from the aforementioned
  198. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>email. Shall the rules be automatically implemented in all 3 involved
  199. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>vms? (&lt;netvm,firewallvm,appvm&gt;). I think yes, because otherwise it would
  200. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>be counterintuitive to be a partially manual and partially automatic
  201. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>operation. But since it actually 'automatically' exposes more attack
  202. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>surface, by loosening up all 3 vms network rules, I guess that maybe
  203. <span class="moz-txt-citetags">&gt; &gt; &gt; </span>more reasoning on it would be helpful.
  204. </pre></blockquote><pre wrap class="moz-quote-pre">
  205. <span class="moz-txt-citetags">&gt; &gt; </span>
  206. <span class="moz-txt-citetags">&gt; &gt; </span>Yes, but you need to pass the traffic somehow. The direct connection can
  207. <span class="moz-txt-citetags">&gt; &gt; </span>be achieved with qvm-connnect-tcp (connecting to the target directly
  208. <span class="moz-txt-citetags">&gt; &gt; </span>using qrexec, bypassing intermediate VMs), but it has its limits (low
  209. <span class="moz-txt-citetags">&gt; &gt; </span>performance, TCP only). To keep it as actual IP traffic, you need to
  210. <span class="moz-txt-citetags">&gt; &gt; </span>change firewall rules at all intermediate VMs too.
  211. <span class="moz-txt-citetags">&gt; &gt; </span>
  212. <span class="moz-txt-citetags">&gt; &gt; </span>Lets have a specific example: in default setup, redirect TCP port 80
  213. <span class="moz-txt-citetags">&gt; &gt; </span>from the outside, to 'work' VM port 8080.
  214. <span class="moz-txt-citetags">&gt; &gt; </span>
  215. <span class="moz-txt-citetags">&gt; &gt; </span>The setup looks like this:
  216. <span class="moz-txt-citetags">&gt; &gt; </span>
  217. <span class="moz-txt-citetags">&gt; &gt; </span> sys-net -&gt; sys-firewall -&gt; work
  218. <span class="moz-txt-citetags">&gt; &gt; </span>
  219. <span class="moz-txt-citetags">&gt; &gt; </span>For this, you will need those rules:
  220. <span class="moz-txt-citetags">&gt; &gt; </span>
  221. <span class="moz-txt-citetags">&gt; &gt; </span>1. In sys-net: forward TCP port 80 to sys-firewall
  222. <span class="moz-txt-citetags">&gt; &gt; </span>2. In sys-firewall: forward TCP port 80 to work, port 8080
  223. <span class="moz-txt-citetags">&gt; &gt; </span>3. In work: allow TCP port 8080
  224. <span class="moz-txt-citetags">&gt; &gt; </span>
  225. <span class="moz-txt-citetags">&gt; &gt; </span>Now is the important design question: how to store those rules? If you
  226. <span class="moz-txt-citetags">&gt; &gt; </span>store them at all three places separately, it
  227. <span class="moz-txt-citetags">&gt; &gt; </span>will be easier to apply them at runtime, but it will be harder to
  228. <span class="moz-txt-citetags">&gt; &gt; </span>correlate them in UI. Plus, if any of them get modified/removed, it may
  229. <span class="moz-txt-citetags">&gt; &gt; </span>be non-trivial to troubleshoot the issue.
  230. <span class="moz-txt-citetags">&gt; &gt; </span>The other approach is to store the forward rules only in one place (the
  231. <span class="moz-txt-citetags">&gt; &gt; </span>target, 'work' in this example? or the source, 'sys-net' here?). This
  232. <span class="moz-txt-citetags">&gt; &gt; </span>way, it's harder to mess thing up. But when applying the rules (building
  233. <span class="moz-txt-citetags">&gt; &gt; </span>rule sets for qubes-firewall service in all the involved VMs), you need
  234. <span class="moz-txt-citetags">&gt; &gt; </span>to check several places.
  235. <span class="moz-txt-citetags">&gt; &gt; </span>Plus, the UI should clearly show such redirected ports at all involved
  236. <span class="moz-txt-citetags">&gt; &gt; </span>places, because it does affect system security - it must be easy to spot
  237. <span class="moz-txt-citetags">&gt; &gt; </span>if any redirects are enabled.
  238. <span class="moz-txt-citetags">&gt; &gt; </span>
  239. <span class="moz-txt-citetags">&gt; &gt; </span>
  240. <span class="moz-txt-citetags">&gt; &gt; </span>To make things more complex (sorry...), there may be a VPN or other
  241. <span class="moz-txt-citetags">&gt; &gt; </span>proxy service (Tor?) involved. For example:
  242. <span class="moz-txt-citetags">&gt; &gt; </span>
  243. <span class="moz-txt-citetags">&gt; &gt; </span>sys-net -&gt; sys-firewall -&gt; sys-vpn -&gt; work
  244. <span class="moz-txt-citetags">&gt; &gt; </span>
  245. <span class="moz-txt-citetags">&gt; &gt; </span>In such a case, the "external" VM for 'work' is not really sys-net, but
  246. <span class="moz-txt-citetags">&gt; &gt; </span>rather sys-vpn. And actually you need to be careful to not accidentally
  247. <span class="moz-txt-citetags">&gt; &gt; </span>bypass VPN either by allowing 'work' to communicate outside of the VPN,
  248. <span class="moz-txt-citetags">&gt; &gt; </span>or (maybe even worse) systems on the LAN (via sys-net) reach inside VPN.
  249. <span class="moz-txt-citetags">&gt; &gt; </span>
  250. <span class="moz-txt-citetags">&gt; &gt; </span>This case is not easy to solve, because currently core-admin has no idea
  251. <span class="moz-txt-citetags">&gt; &gt; </span>whether sys-vpn (or other such VM) do any of such tunnelling. Maybe we
  252. <span class="moz-txt-citetags">&gt; &gt; </span>need to (finally) introduce some flag to mark such VMs?
  253. <span class="moz-txt-citetags">&gt; &gt; </span>
  254. <span class="moz-txt-citetags">&gt; &gt; </span>
  255. <span class="moz-txt-citetags">&gt; &gt; </span>And another question: what should happen if you change netvm of 'work'.
  256. <span class="moz-txt-citetags">&gt; &gt; </span>For example switch to something like:
  257. <span class="moz-txt-citetags">&gt; &gt; </span>
  258. <span class="moz-txt-citetags">&gt; &gt; </span> sys-net -&gt; sys-firewall -&gt; (other VMs, but not 'work')
  259. <span class="moz-txt-citetags">&gt; &gt; </span>
  260. <span class="moz-txt-citetags">&gt; &gt; </span> sys-wifi -&gt; work
  261. <span class="moz-txt-citetags">&gt; &gt; </span>
  262. <span class="moz-txt-citetags">&gt; &gt; </span>Should the redirection stay active via sys-wifi? I think it should not,
  263. <span class="moz-txt-citetags">&gt; &gt; </span>at least not automatically (maybe have an option for that?).
  264. <span class="moz-txt-citetags">&gt; &gt; </span>
  265. </pre></blockquote><pre wrap class="moz-quote-pre">
  266. <span class="moz-txt-citetags">&gt; </span>
  267. <span class="moz-txt-citetags">&gt; </span>I understand all of your points and consequently it is hard to figure
  268. <span class="moz-txt-citetags">&gt; </span>out a catch-all solution.
  269. <span class="moz-txt-citetags">&gt; </span>
  270. <span class="moz-txt-citetags">&gt; </span>I tried charting the flow of the possible solution.
  271. <span class="moz-txt-citetags">&gt; </span><a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png">https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png</a>
  272. <span class="moz-txt-citetags">&gt; </span>
  273. <span class="moz-txt-citetags">&gt; </span>As a sum up:
  274. <span class="moz-txt-citetags">&gt; </span>1) Rules are stored only in &lt;appvm&gt;/firewall.xml
  275. <span class="moz-txt-citetags">&gt; </span>2) Rules can either be internal or exteranl (ie: they are applied only
  276. <span class="moz-txt-citetags">&gt; </span>to &lt;firewallvm&gt; or both to &lt;firewallvm&gt; and its &lt;netvm&gt;)
  277. </pre></blockquote><pre wrap class="moz-quote-pre">
  278. Please note there may be more VMs in between, some examples at:
  279. <a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
  280. So, I think it's better to define it as:
  281. 1. internal: redirect from immediate parent only (VM's 'netvm' property)
  282. 2. external: redirect on the whole chain up to the top (follow 'netvm'
  283. property until you get a VM with it set to None).
  284. My idea of redirect source was to explicitly point where the redirection
  285. starts, instead of this automatic internal/external. But indeed the
  286. automatic may be easier to use.
  287. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  288. <span class="moz-txt-citetags">&gt; </span>3) Forwarding rules should be purged if &lt;appvm&gt; changes &lt;firewall&gt;
  289. <span class="moz-txt-citetags">&gt; </span>(maybe also if &lt;firewallvm&gt; changes &lt;netvm&gt;? But that would be harde to
  290. <span class="moz-txt-citetags">&gt; </span>detect I guess)
  291. </pre></blockquote><pre wrap class="moz-quote-pre">
  292. Or maybe it should be configurable? I'd hate to loose the configuration just
  293. because I temporarily switched to another netvm (and then switched it
  294. back)...
  295. Or, allow both automatic internal/external and explicit redirect source.
  296. Then, setting redirect type to 'internal' would set the redirect point to
  297. the VM's direct upstream (and would automatically adjust if you change
  298. netvm), setting to 'external' would follow the whole chain. But setting
  299. to explicit sys-net for example would always try to apply rule there, if
  300. reachable (and add no rules, if not reachable).
  301. Does it make sense?
  302. Maybe let me explain it on a diagram (see attachment). Especially see
  303. how redirections to appvm3 has changed after switching it from sys-vpn
  304. to sys-firewall: the "internal" redirection (in green) remained there,
  305. but the "sys-vpn" one (in blue) did not.
  306. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  307. <span class="moz-txt-citetags">&gt; </span>4) Users should be able to specify both the forwarded port and
  308. <span class="moz-txt-citetags">&gt; </span>destination port as you were saying
  309. <span class="moz-txt-citetags">&gt; </span>5) Users should be able to eventually restrict forwarding to designated
  310. <span class="moz-txt-citetags">&gt; </span>networks (with 0.0.0.0/0 being the wildcard instead of being a wildcard
  311. <span class="moz-txt-citetags">&gt; </span>by default)
  312. </pre></blockquote><pre wrap class="moz-quote-pre">
  313. I wonder if this should be combined in the same rule, or maybe separate
  314. rule for limiting? But maybe indeed putting it into the same rule may be
  315. easier (avoids duplicating port numbers etc).
  316. </pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  317. <span class="moz-txt-citetags">&gt; </span>However, in this case it will surely be harder to display the rules in
  318. <span class="moz-txt-citetags">&gt; </span>all the affected vms.
  319. <span class="moz-txt-citetags">&gt; </span>The other approach, as you were suggesting, of adding each specific rule
  320. <span class="moz-txt-citetags">&gt; </span>in each vm conf does make sense, but I think then it would necessary
  321. <span class="moz-txt-citetags">&gt; </span>something to keep track of the rule dependencies (such as a unique
  322. <span class="moz-txt-citetags">&gt; </span>identifier). Furthermore there is a higher risk of having orphaned rules
  323. <span class="moz-txt-citetags">&gt; </span>or a inconsistent state.
  324. <span class="moz-txt-citetags">&gt; </span>
  325. <span class="moz-txt-citetags">&gt; </span>Furthermore, in the "internal" vpn case that I have in mind, the idea is
  326. <span class="moz-txt-citetags">&gt; </span>to forward the local port via the VPN interface or Tor (but in the Tor
  327. <span class="moz-txt-citetags">&gt; </span>case users should just stick to Whonix). Some providers, such as
  328. <span class="moz-txt-citetags">&gt; </span>Mullvad, AirVPN, PIA etc allows port forwarding this way and I think
  329. <span class="moz-txt-citetags">&gt; </span>that's the most relevant case since it allows exposing a service on the
  330. <span class="moz-txt-citetags">&gt; </span>internet while maintaining a bit of privacy/anonimity and whithout
  331. <span class="moz-txt-citetags">&gt; </span>needing to bypass the local network NAT. Is this the same case you are
  332. <span class="moz-txt-citetags">&gt; </span>referring to?
  333. </pre></blockquote><pre wrap class="moz-quote-pre">
  334. Yes, exactly.
  335. </pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
  336. <span class="moz-txt-citetags">&gt; &gt; </span>And finally, don't forget IPv6 exists. Which means you can have the same
  337. <span class="moz-txt-citetags">&gt; &gt; </span>port on IPv4 and IPv6. And theoretically they could be redirected to
  338. <span class="moz-txt-citetags">&gt; &gt; </span>different places (but I'm not sure if that's a good idea...).
  339. <span class="moz-txt-citetags">&gt; &gt; </span>
  340. </pre></blockquote><pre wrap class="moz-quote-pre">
  341. <span class="moz-txt-citetags">&gt; </span>
  342. <span class="moz-txt-citetags">&gt; </span>I think that once we have figured out the overall logic to implement, it
  343. <span class="moz-txt-citetags">&gt; </span>should not be hard to duplicate it for ipv4/ipv6. I think the main
  344. <span class="moz-txt-citetags">&gt; </span>problem to think about is to insert proper checks to prevent users from
  345. <span class="moz-txt-citetags">&gt; </span>adding mixed rules.
  346. </pre></blockquote><pre wrap class="moz-quote-pre">
  347. Yes, that sounds about right.
  348. <div class="moz-txt-sig">--
  349. Best Regards,
  350. Marek Marczykowski-Górecki
  351. Invisible Things Lab
  352. </div>
  353. </fieldset>
  354. </pre></div><BR><DIV CLASS="moz-attached-image-container"><IMG CLASS="moz-attached-image" shrinktofit="yes" SRC="EmbeddedImages/0.jpg"></DIV><br><hr><br><div style="font-size:12px;color:black;"><img src="data:image/gif;base64,R0lGODdhDwAPAOMAAP///zEwYmJlzQAAAPr6+vv7+/7+/vb29pyZ//39/YOBg////////////////////ywAAAAADwAPAAAESRDISUG4lQYr+s5bIEwDUWictA2GdBjhaAGDrKZzjYq3PgUw2co24+VGLYAAAesRLQklxoeiUDUI0qSj6EoH4Iuoq6B0PQJyJQIAOw==">
  355. <ul><li><a href="Attachments/network-graph.jpg">Attachments/network-graph.jpg</li></a></ul></div><div class='' ></div></body>
  356. </html>