Tyblog | Building my ideal router for $50

42

Why not use these imported firewall pfsense?

43

Hi @fabiolourenco, I think I mention why not pfsense in the post, but the short version is that I wanted Linux since I would be best able to administer it instead of a *BSD and had some additional features I wanted to experiment with in the Linux kernel.

44

Hi @manpreet! In short terms, hereā€™s what Iā€™m doing in order to visualize my network data:

On my Arch Linux ARM-based router, Iā€™ve installed
the ipt-netflow-dkms-git AUR package. I then load that kernel module on-demand by including the following lines in /etc/shorewall/start:

run_iptables -I INPUT -j NETFLOW
run_iptables -I FORWARD -j NETFLOW
run_iptables -I OUTPUT -j NETFLOW

return 0

You configure the destination for netflow packets in /etc/modprobe.d/ipt-netflow.conf, mine looks like this:

options ipt_NETFLOW destination=127.0.0.1:2055 protocol=5

This is because I run a dynamic reverse proxy on the router to send netflow packets wherever Nomad is currently running logstash, but the tl;dr is that you point the module at wherever youā€™re running logstash.

The logstash config is simple due to the netflow module:

http.host: "0.0.0.0"
modules:
  - name: netflow
    var.elasticsearch.hosts: elasticsearch.service.consul
    var.kibana.host: <my kibana hostname>
    var.kibana.scheme: https

The steps to get Logstash connected to Elasticsearch is outside the scope of the guide Iā€™ve written here. Does that make sense/are there other parts I could clarify?

45

@jrutley I think that use case should be doable. I havenā€™t tweaked my setup very comprehensively, but at the very least, each of the three network interfaces do show up distinctly. Iā€™m not sure what might be implied by the fact that most are of the form @eth0, though.

$ [root@charon network]# ip l | grep -A1 eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
--
4: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc hfsc state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: lan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
46

Great write-ups, I ended up on a PC Engines APU4 but with a similar way of thinking.

Even if I love Arch and has used it as a daily driver for almost a decade now, I wouldnā€™t dare running it on a router (the systemd migration mess still burns) - great to see that itā€™s working fine for you!

With regards to OpenWRT (which is what I am running), If you build your own OpenWRT image from source itā€™s actually a pretty nice flow to have a squashfs root with a writable ext4 overlay (make menuconfig to select packages and configure kernel before compiling). That way you can ā€œreflashā€ and know exactly the state of the system, apart from the config files and user directories which explicitly get copied over between reflashes.

You can still manually opkg install packages and poke around everywhere, so I find it a pretty good workflow so far to test things that way and then incorporate any new/removed packages in a new image (opkg upgrades and conflict resolution leaves a lot to desire though - I started out on a fully writable ext4 root, which quickly became a hot mess of conflicts and annoyance and anyone attempting this should know thereā€™s good reasons the maintainers recommend against this and ā€œopkg upgradingā€ by installin new versions of packages on a running system). The downside is the need to reflash every time you need security updates, of course.