o1bigtenor via Dng <dng@???> wrote:

> 1. is my splitting the network system into the three parts a good idea or should I truncate parts 1 and 2 into the router? If you would please give reasons - - - please?

Six of one, half a dozen of the other. Sometimes having separate boxes is good, other times it isn’t. For example, if you run a router doing NAT (on IPv4) behind a firewall, then the firewall doesn’t see details of where the traffic comes from - only the mangled version where it’s all coming from one address. On the other hand, sometimes it can be tricky making everything work on one box - e.g. doing traffic shaping both ways when there’s multiple internal networks can require an intermediate virtual port (an IFB, intermediate function block, in iptables terminology) to route traffic through and I never did get the hang of that.

> 2. are there any good sources for information on and about networking? 
>      debian has moved to nftables from iptables  - - - is devuan doing similar?

Everything has moved, or will be moving, to nftables - it’s a kernel thing. There’s a shim layer to provide an iptables interface to help people through the transition, but I suspect it might struggle with some of the more complex stuff due to differences in semantics between iptables and nftables.

>      Where does one find information to enable a firewall that works yet isn't stupid?

I’m afraid that’s up there with the answer to life, the universe, and everything - and in this case it’s not 42 ;-)


Back when it was part of the day job, I would “sort of absorb” bits and pieces until I knew enough about networking to be dangerous. After that, it’s a case of recognising when there’s a gap in the knowledge and filling it through reading/research.

Sometimes a good starting point is to have a specific thing you need a pointer to and asking others.


In the past my preferred firewall was Shorewall - it’s quite a steep learning curve, but not as steep as native iptables, and not as limiting as most other firewalls. However, I’m not sure of it’s current status as it was always very tightly bound into the semantics of iptables and would probably need a bottom up re-write to work well with nftables.
But while the learning curve can be steep when past the basics, the examples will let you get common setups going very quickly.
But by far the biggest thing that I liked about Shorewall was the “everything is in a bunch of text files” approach - meaning that you can look at the files and see what’s going on - and, I know this will frighten many used to GUIs, you can put comments in the files to tell you what is going on ! At the same job I mention below, some of the fireballing was down with Zyxel appliances - all though a “rubbish” GUI that makes finding anything difficult and documenting it impossible. Almost a write-only system.

For the ultimate in control, eschew packages and get down and dirty with the native commands - i.e. learn how to drive nftables directly.



tito via Dng <dng@???> wrote:

> I personally prefer x86 hardware for this kind of things

Me too, though there’s some fairly decent small computers about these days. IIRC the rPi4 has a “real” network interface, and gigabit at that - so it would probably make a fairly decent “router on a stick”.

Router on a stick being a reference to something like a lollipop where there’s a “blob” on the end of a single stick. You can use VLANs up this single ethernet link to separate the different classes of traffic - e.g. a VLAN for the connection to your ISP, another for a management subnet for the switches etc, another for the main office LAN, another for a guess WiFi, …
At my last place I had a Debian VM (pre SystemD) with something like 3 DSL (PPPoE) connections, another via an ethernet provider, a backend for inter-server traffic, office LAN, guest LAN, management LAN, and possibly something else as well. Most run on separate VLANs over a single ethernet interface. And all configured with Shorewall.


Simon