I’d like to specifically call out leming for his work on this board. While I helped answer questions and debugging, 99.99% of the work for support was handled via leming, even before the board was publicly accessible!
1 Like
Nothing aside from a short ShieldsUp! scan, which didn’t find anything (ports cloaked). There’s so little running on the board that it’s pretty easy to enumerate what’s listening - I do have some forwarded ports to internal-only LAN hosts, but that’s about it.
I haven’t tried OpenVPN, but I would be curious about the performance. Although it’s a small CPU, it does have some crypto extensions that might aid with OpenVPN/tunnel performance. Here’s the lscpu output, which shows that the CPU does have AES and several checksum extensions, so OpenVPN performance may not be too bad.
[root@host ~]# lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Vendor ID: ARM
Model: 4
Model name: Cortex-A53
Stepping: r0p4
CPU max MHz: 1000.0000
CPU min MHz: 200.0000
BogoMIPS: 25.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
Hello, I have build the router, it’s a real nice project. It is running, but I am stopped on Part Five, at building ‘ipt-netflow-dkms-git’.
My command is:
yaourt -S ipt-netflow-dkms-git
but I encounter the following build error:
==> Building and installing package
==> ERROR: ipt-netflow-dkms-git is not available for the ‘aarch64’ architecture.
==> ERROR: An unknown error has occurred. Exiting...
==> ERROR: Makepkg was unable to build ipt-netflow-dkms-git.
I have read about the issue you encountered, but did not found how to get around the “not available for the ‘aarch64’ architecture.” error.
Did I miss something?
With all my thanks for this project,
Gaetan
I’m glad to hear the build is running for you, that’s great!
I forgot to mention that the AUR PKGBUILD for ipt-netflow doesn’t currently list aarch64 as a supported architecture. If you edit the arch list to include aarch64 manually, the build should compile, install, and run just fine on the espressobin.
It’s been many months since I’ve started using netflow monitoring on the firewall at this point without any problems whatsoever, so I think aarch64 is a supported architecture for the module - I’ve just commented on the AUR package to request that aarch64 be added, so hopefully the maintainer does so in order to avoid making people add the architecture manually.
Thank you for your answer. After including ‘aarch64’ in the arch list, building the package went smoothly.
I followed your tuto to create the .conf files and loaded the ipt_NETFLOW module.
I got a warning: ‘ipt_NETFLOW: loading out-of-tree module taints kernel’, but no error.
I could not verify the content of the capture, because Arch Linux does not have a Logstash package. There is a Elasticsearch package, but I have still to look if it is the full stack (with Logstash) and find how to use it.
Anyway, I could verify with netcat that some data is sent to the port 2055 of my server:
netcat -u -l -p 2055 > netflow.capture
Update to my former post.
There is an Arch Linux Logstash package for x86_64 architecture. I didn’t found it at first, because I was searching for my home server, an ODROID-HC1, whose arch=armv7h.
So, after installing the ELK stack (Elasticsearch, Logstash, Kibana) on a x86_64 machine, and starting the services, I could resume the ‘Netflow Monitoring’ section of your tuto, and have those nice Kibana reports. I was really impressed to have all this working. Hopefully, you gave sufficient clues to know where to go.
Many thanks to you for having written this tuto.
About building ipt_NETFLOW DKMS module on Arch Linux:
For information:
- there was an error building ipt_NETFLOW DKMS module with kernel linux-espressobin 4.17.0 … 4.17.4
- good news: building the module is anew ok with kernel linux-espressobin 4.17.5 and (today) 4.17.6
Wow! its an amazing guidance and a beneficial blog .It is quite amazing and the way you explained it step by step it was fabulous.I have been looking for a walkthrough like it for a very long time but couldnt find a proper one and at last I finally found it and also it is amazing.You are a great blogger.williamjacket
That’s an exquisite piece of work! Can I know what modem do you use with this build?
Hi @EdenSajid, pretty much any modem will work with this setup, as long as the espressobin can get a DHCP address. At the moment I’m using this Netgear modem, which as been running for about a year.
@tylerjl Thank you so much for the tutorial. It’s been great playing with the espressobin! My current setup is practically identical to yours minus all the NETFLOW stuff. I’m noticing a huge reduction in speedtest when switching from my current pfsense router to the espressobin. I typically get 200down/11up with pfsense. With espressobin I’m getting 45down/15up.
I’ve gone over all the tcdevices and tcclasses and don’t see why it’s being limited. Any thoughts?
Thanks
Hmm, I haven’t observed any significant slowdowns moving from a traditional router to a homebrew espressobin. I will say that the espressobin drivers and upstream support is still pretty active/in development - what distribution/kernel are you running?
Linux alarm 4.18.14-1-ARCH #1 SMP Sat Oct 13 18:35:28 MDT 2018 aarch64 GNU/Linux
I followed your tutorial almost to the letter. I used http://wiki.espressobin.net/tiki-index.php?page=Boot+from+removable+storage+-+ArchLinux to setup the sdcard boot device.
Any of your updates break the router so far or have you been stable? How often do you update?
I update the router about once a month, just to ensure all the relevant packages are kept current with upstream. So far the only breakages have been in kernel incompatibilities with the ipt-netflow module, but I think that’s only happened once so far - any Arch updates to shorewall, dnsmasq, etc. have been stable.
First let me thank you for that great blog post!
Over the weekend I tried to follow you guide but I came across a curious, at least for me, problem. Ip forwarding seems only to work if I start the network service after the shorewall service. On the clients when I try to traceroute any webaddress, im stuck at the router, after stopping and starting systemd-networkd.service the route completes. Is this normal behaviour and I just did something wrong, or did you take care that the network service starts after the shorewall?
Hmm, I haven’t modified either the systemd-networkd service or the shorewall service. I believe that indicating the wan and br0 interfaces should be configured for IPv4 is sufficient - here’s my relevant files:
[root@router ~]$ cat /etc/systemd/network/br0.network
[Match]
Name=br0
[Network]
Address=192.168.1.1/24
IPForward=ipv4
IPMasquerade=yes
ConfigureWithoutCarrier=yes
[root@router ~]$ cat /etc/systemd/network/wan.network
[Match]
Name=wan
[Network]
IPv6AcceptRA=no
DHCP=ipv4
BindCarrier=eth0
IPForward=ipv4
[root@charon ~]#
As far as I know, this should set the interfaces into a forwarding state.
Any particular reason you went for classfull qdisc rather than e.g. cake?
The piece-of-cake recipe from openwrt works very well for me, but, otoh, I don’t really know what it’s doing.
I read up on traffic shaping strategies for a long time before finally just settling on using eqhmcow’s strategy primarily because I felt like I understood the class choices and it seemed to fit my use case.
I suspect that latest-and-greatest traffic shaping algorithms (used to be codel, now cake) may achieve the same results, honestly. My understanding is that the tradeoff is router load, but after my time with the espressobin, I certainly think that it could handle the additional processing power.
My hope is that I can provide a revisit of my router setup after a while and spend some time benchmarking cake versus other options to verify whether it works, but if anyone wants to experiment, my understanding is that the module(s) are readily available from the Arch repositories/AUR.