I know there is OpenWrt, but my experience is that is more geared toward running on embedded wifi hardware than an x86 machine. The x86 install comes with a tiny root partition that's actually pretty difficult to resize, for example, and upgrades are quite brittle compared to standard Linux distros.
And there's also pfSense and OPNsense, but these run on FreeBSD which seems to lag behind Linux for hardware support. There's no support for the Aquantia AQC113 NIC, for example (although it looks like this may finally have been added in the last month or so).
Something like an Ubuntu Appliance [1] would be quite nice.
Keep in mind most network appliances have dedicated hardware hand-off adapters, and so the CPU isn't involved in routing once the connection is setup. It is why people can use a $30 SoC, and still be able to saturate several 10Gb/100Gb ports. =3
One thing I’d add, is that the best explanation I’ve ever seen for this, is the famous diagram [0] on Wikipedia of the netfilter API — I remember when I saw that, everything clicked into place. I’m not sure how up to date it is now, but it’s really good.
[0] https://commons.wikimedia.org/wiki/File:Netfilter-packet-flo...
So now I do not do any funky stuff with firewalls anymore. Separate appliance with opnsense bare metal.
My router is a 16GB n150 mini PC with dual NICs. The actual router OS is within openwrt VM managed by Incus (VM/Container hypervisor) that has both NICs passed through.
One of the NICs is connected to another OpenWrt wifi access point, and the other is connected to the ISP modem.
The n150 also has a wifi card that I setup as an additional AP I can connect to if something goes wrong with the virtualization setup.
Been running this for at least 6 months and has been working pretty well.
For example, bandwidth rate-limiting may be inhibited for admin SSH or package updates, and LAN IPv4 private ranges for your host address pool are set.
Finally, your internal DHCP should statically bind your admin computer MAC to a fixed LAN host IP to further reduce issues.
Personally, I always build my NAS from scratch, as I have lost count of the number of problems web-GUI have caused over the years. =3
Btw you do also need to be careful with opnsense. I was years behind on updates for mine because every time I updated I assumed that it would bring me up to date with the latest version. But opnsense has to install the upgrades in order. After you reboot you need to check again for updates and repeat until there's no more to install.
An x86 mini PC can run all this without breaking a sweat; using separate appliances seems very wasteful. That being said, I configure everything in DIY mode, and don't rely on GUIs or other similar things that increase the attack surface considerably.
I think your initial setup was perfectly valid. Then you diagnosed a fault and fixed it with aplomb, in a way that you could verify. The key point is: "in a way you could verify" and you failed safe. Well played.
Proxmox itself has a useful firewall implementation too, although it takes a bit of getting used to because you can set it at the cluster, host and VM levels. I personally love it because it is easier to manage than individual host based firewalls, which I also do, but I'm a masochist! For smaller systems I generally use the cluster level to keep all the rules in one place.
- net.ipv6.conf.all.forwarding=1
- nftables is default to `ip` family which only applies to IPv4. Setting it to `inet` will allow rules to apply to both IPv4 & 6; or `ip6` for IPv6 only. You can skip NAT rules, usually.
- dnsmasq: in addition to DNS and DHCP, turns on router advertisement with SLAAC. Some devices can get IPv6 address from stateful DHCPv6 server, others (e.g. Android) only work with SLAAC.
As a kid with no AI, no google, it was quite a feat and I’m still very proud of it
Was my introduction into how the internet works and I’ll never forget working with ipchains
I remember enduring a lot of people in forums calling me a noob, but only after spending collective hours answering my dumb questions
I credit a big part of my moderate success in tech, to being familiar with stuff at just a tad bit lower of a level than the average bear
To my friend Sam who I haven’t talked to in 20 years, thanks for the idea
It's like me stating "you're not a man, you're a human!" and then expecting you to be in awe of my profound wisdom.
IPv6 support is not required for a router. You'll note they also fail to offer IPX/SPX or ATM and many more.
https://en.wikipedia.org/wiki/Customer-premises_equipment
Given that the Wikipedia definition of CPE includes routers, I don't see how calling it CPE precludes it being a router, as the poster claimed:
> That's not a router, that's a CPE, and one without IPv6 support
For a Linux box to be a true CPE you'd likely need somewhat of a specialized card, one that can communicate directly to the next device up the line (e.g, take commercial fiber or cable in, ISDN modem, etc).
If it just shoots out ethernet into some other box next to it, it's likely not a CPE.
I've never heard of that before. How does that work? Your ISP would always have to have some infrastructure within 100 meters of your router then.
> CPE generally refers to devices such as telephones, routers, network switches, residential gateways (RG), set-top boxes, fixed mobile convergence products, home networking adapters and Internet access gateways that enable consumers to access providers' communication services
From my understanding any type of device that is used to extend or facilitate provider services is a CPE. So a router just acting as an extender would still be a cpe, as would a modem, as would anything that is on the customer side and facilitates provider services. Only situation a router wouldn't be a cpe is if it was just for a local lan network.
At home I've got both a CPE given by my ISP and my own router that routes and bridges traffic between two LANs of mine (192. and 10.).
Moreover the lack of IPv6 inside our own LANs is, for many of us, a feature. It doesn't mean we don't have an IPv6 address: it just means we have the choice and did choose to have our own LANs on IPv4 only. And, no, I don't care that it makes some programmers at some megacorp' lives more difficult to "reach" inside my networks.
I'm the boss at my home and my router is IPv4 only.
And I've got that in addition to my ISP's CPE.
IMO, it’s a plain old router/switch/bridge.
You need to explicitly reconfigure the iptables/nftables to prevent that from happening.
Some software, say LXD/Incus, enable forwarding automatically upon installation/startup, and do not configure firewall to block non-their traffic, making the machine an open router. I've reported that, the developers said that's by design (despite other virtualization/containerization systems block forwarding if they happen to enable the sysctl).
“The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.”
In the setup I presented, we are bridging an Ethernet and a WiFi network. This would be desirable if you wanted to use an upstream dhcp server for your WiFi clients- or if you wanted to avoid double nat’ing.
In 802.11 infrastructure mode, a station can only send frames with its own MAC address. The AP won’t accept or forward frames from unknown MACs. So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd.
In every other circumstance- I think your statement holds.
I tried to do some weird alerting on new MAC addresses and ran into this weirdness. Bridging WiFi and Ethernet gets weird.
- router
- NAT gateway
- DHCP server
In a typical scenario, turning IP forwarding on will do nothing unless:
- DHCP has given the devices on the 'inside' IP addresses and told them the gateway address, and
- the router is set up to do IP masquerading
As for the GP's example, running VM's or containers* on your own machine? I'd say the default ACCEPT policy is fine. However, silently changing such a setting on software installation is a problem because if the machine is multi-homed (i.e. has more than one network interface), you've now created a network route outside of the network admin's control.
* The default for docker and podman is to use a private network, not a bridge anyway.
Setting that up with safe/fair bandwidth-sharing requires intermediate IT skill level. Still a great hobby project =3