I’ve added some more NAT networks, and since for every network I have to add drop policies to prevent crosstalking to other NATs it have become a nightmare to add even one NAT.
Using -P INPUT DROP doesn’t seem to have any effect at all
So, how do I prevent any packet from ethX being transfered to ethY and the other way around, but (both) still being able to access the public internet over eth0?
And per-interface or address policies are not valid solutions to my problem, only global ones are welcome.
Your drop policy probably doesn’t appear to drop traffic because you used the INPUT chain in the filter table which only affects traffic ultimately bound for that machine. You need to use the FORWARD chain of the filter table to stop traffic merely traversing the machine.
And you don’t have to use positive only rules. You can drop the complement of what you want to accept so:
Just a thought … Instead of something that acts like a router, consider deploying router.
I began using pfSense a decade ago, because its’ brilliant and easy to use traffic shaping tool made my horrible DSL connection tolerable. But, I quickly found that it offers other great features, as well. Long story short, I have my devices/traffic segmented across a couple of LANS and VLANS. pfSense will happily route traffic between the various networks, but unless I add firewall rules permitting this, the networks remain isolated. This gives me fine grain control on which hosts can see which hosts (or not), via a few simple firewall rules, instead of deploying complicated routing tables. pfSense also makes it easy for me to implement a default deny egress policy, whereby traffic can’t even reach the Internet, unless I specifically permit it with a firewall rule(s).
Ubuntu desktop will do as much as any other OS, we have OSes made to do this that come with every thing you will need and even more so a large support community that has most likely done/posted what you are trying to do
AlpineLinux and Linux in general is more than enough suited to act as a router of the box thanks to it’s networking capabilities.
Why should I bother with pfSense and KVM when I can just use LXC and save on resources. Also, instead of using pfSense I would rather use ipFire if I’d have to run something in KVM.
P.S
please note that using full virtualization for just simple NAT routing/port forwarding and Nginx proxy seems to be just overkill.
In the OP’s linked conversation, he says that he is running something in a container that acts like a router. Obviously all any of us needs is Linux From Scratch and iptables, but life is too short. Why not stand on the shoulders of giants and deploy a tool made specifically to address the problem at hand? pfSense is an elegant solution, with a friendly interface, which includes many other tools which may be useful in this application.
Obviously, there are many other possible solutions, so YMMV.
