Yes, but I may be interested in running some apps in docker as pi resources proven to be plenty under your experiments, hence the ask for the configuration guide if you can share it.
Is something like Intel Celeron J4105 appropriate? If I can't use OpenWrt, would PfSense be a good replacement in that case?
you can use OpenWrt for the Celeron no problem.
under raspbian I just wrote a custom nftables firewall and a custom set of /etc/systemd/network files (to bring up the LAN interface with a static IP and ipv6 ill post those a little later when I have access to grab them) and voila it's a router. You could install something like cockpit to get a web admin page... I've never used it.
I guess I installed dnsmasq and configured that to do DHCP and router advertisements on the LAN. it's literally uncomment a couple lines in the config file.
you can search the forum for my recent thread on nftables to get started there, it works out of the box on raspbian since they don't have iptables installed so the debugging going on over there isnt necessary.
Beyond literally an nftables.conf file, a minor mod to the dnsmasq file and two .network files I don't think I did anything else except maybe install a couple packages like emacs or whatever you like to have available to you.
if you want something like SQM you would have to use tc to put cake on the Ethernet interfaces manually. the man page for tc-cake might be enough info there.
edit: you can run openwrt in an lxc container, Google for that on the wiki. so one strategy might be to install raspbian, then put OpenWrt in an lxc container to gain the luci interface and router oriented configs, and run your other containers alongside...
sqm can run under systemd, so you might be able to install and run it under raspbian as well.
Sure, and for a number of use-cases that is a great idea! Just keep in mind that containers share one kernel and there, unfortunately, is some leakage of kernel data across containers (but also across VMs so a hypervisor will not guarantee complete safety here) can happen. Since the router container will be dealing with potentially hostile network data/traffic just make sure the other containers are not too sensible (exfiltration of data is unlikely, but not impossible).
1 Like
Right, if you're running PiHole and an asterisk server it's probably fine but if you're storing a high value cryptocoin wallet or something make it a separate box with just the high value app.
Here are the network files I put up for systemd:
/etc/systemd/network/10-eth0.network
[Match]
MACAddress=xxxxxx
[Link]
RequiredForOnline=no
[Network]
DHCP=yes
IPForward=yes
DefaultRouteOnDevice=yes
IPv6PrivacyExtensions=yes
IPv6AcceptRA=yes
IPv6PrefixDelegation=static
[IPv6PrefixDelegation]
Managed=false
RouterLifetimeSec=300
RouterPreference=medium
[IPv6RoutePrefix]
Route=fdxxxxx::/64
You should probably make "requiredforonline" no because it will wait for your ISP before it lets you do things like log in to administer... so if your ISP isn't available you can't effectively reboot it and fix configs.
/etc/systemd/network/10-eth1.network
[Match]
Name=eth1
[Network]
Address=fdxxxxxxxx::1/64
Address=192.168.x.x/24
IPForward=yes
IPv6AcceptRA=no
IPv6PrefixDelegation=no
[IPv6Prefix]
Prefix=fdxxxxxx::/64
dnsmasq does the prefix delegation and dhcpv6, so we prevent systemd from getting involved
and in dnsmasq.conf:
# If you want dnsmasq to listen for DHCP and DNS requests only on
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
# Repeat the line for more than one interface.
interface=eth1
...
dhcp-range=fd5xxxxx::, ra-only
dhcp-range=192.168.1.20,192.168.1.150,1h
That's about it at the minimum, obviously you can improve things by customizing.
2 Likes
Is 4G ram a little bit over killed for a router?
not if you plan to run other services on it, maybe in containers, like asterisk or nextcloud or samba or an ldap directory or whatever. yes if it's dedicated just as a router. the 1Gig version should do fine for that.
It all depends on what you want to accomplish in the end. Both OPNsense and pfSense are both very nice distros with a lot of nice features integrated in the frontend which OpenWrt lacks however that's mainly because they're targetting different types of hardware however wireless support is by far better in Linux which favours OpenWrt in that regard. As far as docker goes you're probably better off with a Linux distro as Docker isn't really a thing in (Free)BSD, however you have both jails (https://www.freebsd.org/doc/handbook/jails.html) and bhyve (https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html) which may be good alternatives. Whether you should run multiple services or not on a router/firewall is up to you to decide but I will warn you that some have very strong opinons about this approach. As for CPU a Celeron J4150 will be just if you don't do anything too crazy irregardless of OS/distro.
My personal choice of OS is highly dependant on hardware used (regarding networking):
MIPS/ARM: OpenWrt (if wireless is embedded into the device)
x86: Something designed for more powerful hardware and takes advantages of it, usually I personally end up with FreeBSD however there are multiple choices here which you may want to consider such as ClearOS and others including the ones mentioned earlier).
Wirless devices (only acting as AP or such): OpenWrt
Unless you can tolerate downtime etc I would personally avoid any kind of solution that requires USB NICs or such however that solution might be good enough for you. The amount of RAM need will be highly dependant on distro and what functionality you want to use. If you want to "plain" firewall 128Mb will be fine however if you start to adding logging and other functionality including wifi it quickly ramps up. Running OpenWrt 256Mbyte will most likely be find but it would be able to handle much more than basic firewalling and handling wireless. A firewall distro that targets x86 usually "expects" 1-2Gb (at least) to run decent but you may want to add more if you're planning to do IDS etc (you'll also need a beefier CPU).
1 Like
10 posts were split to a new topic: RPi4 installation
The nanopi r2s?
Seems interesting once it's available.
1 Like
Yeah, it's not as powerful as RPI4, but if the second LAN over USB port is more reliable than an external Ethernet adapter then it could be a good device.
Unfortunately it's second ethernet is from a USB 2 controller, which means it can only has up to 480Mbps throughput.
That's for the first iteration (R1S). The new one (R2S) is supposed to have Ethernet from USB 3 (and also RAM upgraded to 1 GB).
1 Like
That's very interesting. Nice to be aware of the news.
They claim 941Mbps on both ports.
Espressobin would also be worth a look. $79 including enclosure on Amazon.
It has 3 Gigabit ethernet ports but they are connected to a switch chip on the board, with only one Gigabit port on the CPU. So it can't route gigabit bidirectionally, but it has USB 3 so you can always fall back to an external NIC if it's not fast enough.
Also there's a mini-PCIe slot so you can add a WiFi card, though personally I would use an external access point instead.
1 Like
The CPU in the Espressobin supports
- 2 x Gigabit Ethernet 1Gbps / 2.5Gbps
- SGMII / HS-SGMII / RGMII
The switch chip is a Marvell Topaz 88E6341 which has
- 4 integrated GE PHYs
- 1 SerDes/SGMII supporting 2.5Gbps or 1Gbps
- 1 RGMII/MII/RMII
The SoC is connected with 2.5Gbit (full duplex) to the switch.
Another option is the GL-iNet GL-MV1000 Brume which has the same CPU and Switch, but has better heat management.
Maybe in the v7 but I don't think this is true in the v5.
Oh cool, I didn't realise the RGMII could be faster than 1Gbps. It's too bad they didn't use both the ports on the CPU anyway.
Tested the RPi 4B based router, it's not like what I expected though, the DSLreport test result is at the same level as D-Link DIR-860L B1, upload is slightly better than 860L, but the download is actually worse.
This is the result with RPi 4B.
Test results at https://www.speedtest.net/ however, is quite impressive with RPi 4B, it's over 900Mbps downloading.