After my Asus N66U kicked the bucket, I considered a few options: another all-in-one router, upgrade to something like an EdgeRouter, or brew something custom.
When I read the Ars Technica article espousing the virtues of building your own router, that pretty much settled it: DIY it is.
I expect the EspressoBin has good performance with OpenVPN. I ordered an EspressoBin in the initial Kickstarter, but have not needed to use it yet. (Given that the EBin a ādevā board, installing Armbian looks to be more work than installing Raspbian on an RPi. This has deterred me, at least temporarily. Friction, you know.)
ZeroTier (which is similar to OpenVPN) sells a network appliance based on the EspressoBin.
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!
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.
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.
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
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?
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?
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.