Qubes
/
gsoc


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111
							<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Re: GSoC Port Forwarding</title>
<link rel="important stylesheet" href="">
<style>div.headerdisplayname {font-weight:bold;}
</style></head>
<body>
<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>Giulio <giulio@gmx.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>15/08/2021, 17:35</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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</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>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>Thank you for you fast reply.
<br>
<br>Il 14/08/2021 23:43, Marek Marczykowski-Górecki ha scritto:
<br><blockquote type=cite style="color: #007cff;">
<br>As for the nft syntax, I think iptables-translate tool can help you
<br>(part of the iptables-nft package).
<br>See <a class="moz-txt-link-freetext" href="https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables">https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables</a>
<br>
<br><blockquote type=cite style="color: #007cff;">You can see in [4] how I organized the forwarding mechanism. All the
<br>necessary information, as well as ipv4/ipv6 support should already be in
<br>the 'prepare_forward_rules' function meaning that only the actual
<br>building syntax is left.
<br></blockquote>
<br></blockquote>
<br>I have tried to write the external nft rules as well the extarnal ones, 
with the exception of the destination domain.
<br>
<br>Assume the following setup:
<br>sys-net - 10.137.0.5 (ens6 phy with 192.168.10.20)
<br>sys-firewall - 10.137.0.6
<br>personal - 10.137.0.7
<br>
<br>All of them are running fedora-32.
<br>
<br>And assume the following rule added via qvm-firewall:
<br># qvm-firewall personal add action=forward forwardtype=external 
scrports=22-22 proto=tcp dstports=2222-2222 srchost=192.168.10.0/24
<br>.
<br>First, a table for the forwarding rules is created:
<br>
<br>flush chain {family} qubes-firewall-forward prerouting
<br>flush chain {family} qubes-firewall-forward postrouting
<br>table {family} qubes-firewall-forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain postrouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type nat hook postrouting priority srcnat; policy accept;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; masquerade
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain prerouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type nat hook prerouting priority dstnat; policy accept;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<br>}
<br>
<br>Then, if the qube is marked as 'last', meaning that it is the external 
qube with the physical interface the following rules are added:
<br>
<br>table {family} qubes-firewall-forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain prerouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "ens6" {family} saddr 192.168.10.0/24 tcp dport {{ 22 }} 
dnat to 10.137.0.6:2222
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>table {family} qubes-firewall {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "eth0" {family} daddr 10.137.0.6 tcp dport 2222 ct state 
new counter accept
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>And that is all for sys-net.
<br>
<br>In sys-firewall, since it is an 'internal' qube, the following rules are 
added instead:
<br>
<br>table {family} qubes-firewall-forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain prerouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "eth0" {family} saddr 120.137.0.5 tcp dport {{ 2222 }} 
dnat to 10.137.0.7:2222
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>table {family} qubes-firewall {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "eth0" {family} daddr 10.137.0.7 tcp dport 2222 ct state 
new counter accept
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>Lastly, the appropriate rules allowing incoming traffic on the selected 
port from the previous hop should be added directly yo the 'personal' 
domain. However I see that there the nft ruleset is empty, while 
iptables seems indeed to be in use. I guess that those rules are the 
ones specified in qubes-core-agent-linux/network/iptables, however I am 
wondering how we should proceed on this one?
<br>
<br>Also are you able to spot errors or something missing in the 
aforedescribed rule flow? When testing I can see the incoming connection 
on port 22 of the physical interface of sys-net, but then I am losing 
track of the connection after that...
<br>
<br>
<br><blockquote type=cite style="color: #007cff;">In both cases, the code will need some tests of course.
<br>
<br></blockquote>
<br>As soon as everything seems to work with my manual test, I will start 
progressively writing the automated tests.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>