Re: Introducing shorewall-nft

--===============7053626993695458515==
Content-Type: multipart/alternative; boundary="00000000000075e6c20657194cec"

--00000000000075e6c20657194cec
Content-Type: text/plain; charset="UTF-8"

On Tue, 21 Jul 2026 at 16:01, Sam via Shorewall-users <
[email protected]> wrote:

> On 7/18/26 11:55 PM, Dave Kempe wrote:
> >
>

Thanks Sam. Sorry I didn't know about this project.


>
> Dave, perhaps you have noticed but I also started a shorewall-nf project:
> https://github.com/smith153/ShorewallNF
> With docs at:
> https://smith153.github.io/ShorewallNF/
>
> The tests say everything is "working" but I have not tried running
> the code outside of a VM. If you are truly running shorewall on customer
> hardware, you are in a much better place to test the end product than I.
> I am perfectly happy stopping development on my project and letting you
> have the full lead as I haven't really put too much of my own time into
> mine.
>

Yes we have a tonne (high hundreds) of shorewall setups we support for all
sorts of different applications and networks.


Where I did spend quite a bit of time though is the overall
> architecture. So for your own consideration:
>
> I too went with python. I did not want to move away from Perl as I know
> 10 years from now what ever I wrote in Perl would still be runnable.
> Can't say the same with python but going with python would make it a
> much more easy sell and ultimately that wins.
>
> The next decision I faced was what to do about ipv4 and ipv6. Should we
> treat the two as purely separate like shorewall? Since nftables handles
> both protocols, it seemed the right way to go was with one config and
> one rules file which could configure both stacks. Not sure if that is
> the direction you went, might be worth community feedback.
>

I did actually start with a single 'inet' table, however as we went on, I
realised that was the wrong approach.
Docker has its own table, and ipv6 and ipv4 having seperate tables made
sense, particular as we wanted to get nft sets working.
ipsets aren't the same in nftables, so nft sets have to be seperate and we
ended up spliting into seperate tables due to this, docker and it just
being easier to reason about.


>
> Next up was where to handle TC and overall network topology config. I
> decided to offload that to systemd, which worked best for my current
> setups since I'd already been fighting conflicts between Shorewall and
> systemd anyway. Not sure if that's the right call for a dedicated
> firewall hardware appliance, though.
>
>
As much as I have come to appreciate systemd, it has already overreached in
my grouchy old linux dude opinion.
The deal here has to be drop-in 100% of existing setups are usable with
either minimal translation to the nft world, or a loud warning at worse.
So bugs that prevent migration will be attended to swiftly, as I can't have
stuff breaking in the field.
Truck rolls are expensive as they say.

Happy to take any feedback, and please feel free to actually test it out!

Dave

--00000000000075e6c20657194cec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 21 Jul =
2026 at 16:01, Sam via Shorewall-users &lt;<a href=3D"mailto:shorewall-user=
[email protected]">[email protected]</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/18/26 11=
:55 PM, Dave Kempe wrote:<br>
&gt;=C2=A0<br></blockquote><div><br></div><div>Thanks Sam. Sorry I didn&#39=
;t know about this project.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">
<br>
Dave, perhaps you have noticed but I also started a shorewall-nf project:<b=
r>
<a href=3D"https://github.com/smith153/ShorewallNF" rel=3D"noreferrer" targ=
et=3D"_blank">https://github.com/smith153/ShorewallNF</a><br>
With docs at:<br>
<a href=3D"https://smith153.github.io/ShorewallNF/" rel=3D"noreferrer" targ=
et=3D"_blank">https://smith153.github.io/ShorewallNF/</a><br>
<br>The tests say everything is &quot;working&quot; but I have not tried ru=
nning <br>
the code outside of a VM. If you are truly running shorewall on customer <b=
r>
hardware, you are in a much better place to test the end product than I. <b=
r>
I am perfectly happy stopping development on my project and letting you <br=
>
have the full lead as I haven&#39;t really put too much of my own time into=
 <br>
mine.<br></blockquote><div><br></div><div>Yes we have a tonne (high hundred=
s) of shorewall setups we support for all sorts of different applications a=
nd networks.</div><div></div><div>=C2=A0</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
Where I did spend quite a bit of time though is the overall <br>
architecture. So for your own consideration:<br>
<br>
I too went with python. I did not want to move away from Perl as I know <br=
>
10 years from now what ever I wrote in Perl would still be runnable. <br>
Can&#39;t say the same with python but going with python would make it a <b=
r>
much more easy sell and ultimately that wins.<br>
<br>
The next decision I faced was what to do about ipv4 and ipv6. Should we <br=
>
treat the two as purely separate like shorewall? Since nftables handles <br=
>
both protocols, it seemed the right way to go was with one config and <br>
one rules file which could configure both stacks. Not sure if that is <br>
the direction you went, might be worth community feedback.<br></blockquote>=
<div><br></div><div>I did actually start with a single &#39;inet&#39; table=
, however as we went on, I realised that was the wrong approach.</div><div>=
Docker has its own table, and ipv6 and ipv4 having seperate tables made sen=
se, particular as we wanted to get nft sets working.</div><div>ipsets aren&=
#39;t the same in nftables, so nft sets have to be seperate and we ended up=
 spliting into seperate tables due to this, docker and it just being easier=
 to reason about.</div><div></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
<br>
Next up was where to handle TC and overall network topology config. I <br>
decided to offload that to systemd, which worked best for my current <br>
setups since I&#39;d already been fighting conflicts between Shorewall and =
<br>
systemd anyway. Not sure if that&#39;s the right call for a dedicated <br>
firewall hardware appliance, though.<br><br></blockquote><div><br></div><di=
v>As much as I have come to appreciate systemd, it has already overreached =
in my grouchy old linux dude opinion.</div><div>The deal here has to be dro=
p-in 100% of existing setups are usable with either minimal translation to =
the nft world, or a loud warning at worse.</div><div>So bugs that prevent m=
igration will be attended to swiftly, as I can&#39;t have stuff breaking in=
 the field.</div><div>Truck rolls are expensive as they say.</div><div><br>=
</div><div>Happy to take any feedback, and please feel free to actually tes=
t it out!</div><div><br></div><div>Dave</div><div><br></div><div><br></div>=
</div></div>

--00000000000075e6c20657194cec--


--===============7053626993695458515==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7053626993695458515==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline