Skip to main content

Keeping the Wireguard VPN firewall clear with Shorewall

In our previous article we introduced the iptables firewall for our Wireguard VPN server. The firewall regulates which traffic is permitted between the individual customer VPNs and the management VPN and prevents access that poses a security risk.

Although it is possible to manage these rules using the iptables command line tools, it quickly becomes confusing and difficult to understand, especially for outsiders. We have therefore tested the firewall configuration using the “Shorewall” tool and found it to be suitable.

Securing a multi-tenant Wireguard VPN server with iptables

The ZERO AMPS Nodes do not have an internet connection by default, but in some cases we equip them with a mobile module so that we can update, maintain or troubleshoot them remotely.

To establish a secure connection to our own infrastructure, we mostly use Wireguard VPNs. Wireguard VPNs are very lightweight, perform well and experience has shown them to be very robust - especially in combination with mobile connections. The Wireguard client on the AMPS nodes connects to our central VPN server. Our developers also use this to establish a connection so that they can connect to the respective AMPS node.

Setting up a lab network on Linux

During my work, I regularly connect to various computers and embedded devices that are accessible via an Ethernet connection. These could now be connected directly - like the development computer - to the company network…

… or you can create your own “lab network” for your devices, which is only accessible from your own laptop and over which you have full control. Advantages can be:

  • Overview of the connected devices and their IP addresses.
  • No exposure of the connected devices to the company network (improvement of security)
  • If only Wifi is available at the development computer, the embedded devices can still be reached easily and wired.

In larger companies, access to the internal company network may also be heavily regulated, so that only unlocked devices can be used at all. With an own small laboratory network on a second network interface, this problem can be elegantly circumvented.

Using a Mikroe CAN SPI Click 3v3 Module on a Raspberry Pi 4

Mikroelektronika (MikroE) from Serbia offers within its “Click” ecosystem numerous function modules that can be operated on microcontrollers. One of them is the “CAN SPI Click 3.3V” CAN controller module, which can be connected via the standardized “MikroBus” interface or SPI. To make the connection to a Raspberry Pi 4 work, we added the “Pi 4 Click Shield”.

In this post we will briefly explain how we got the CAN module working in conjunction with the Raspberry Pi 4.

Set default DNS resolver for Dnsmasq on Raspbian Buster

On one of our Raspberry Pis with Raspbian “Buster” image we had a strange problem in combination with a USB mobile stick: The Wireguard VPN client could not connect correctly to the Wireguard server again and again when starting the Pi. The error log said that the hostname of the Wireguard server could not be resolved in the client configuration.

A possible cause for this could be that at the time the Wireguard server was started, the internal DNS resolver of the mobile stick (NAT/router operation) was not yet operational and resolution failed because of this. To confirm the theory and fix the error, a default name server should now be introduced, which is always the same regardless of the network connection and is available immediately.

Using Quectel RM520M and Telit FM990A28 5G Modem with Raspberry Pi OS

On our odyssey in search of a 5G cellular modem, we have tried several modems from different manufacturers. Unfortunately, the commissioning was not always successful. Sometimes the driver support in the Linux kernel was completely missing - sometimes the control via NetworkManager / ModemManager was buggy or not possible at all.

Easy commissioning and stable operation are important to us. Since we do not want to use the modems on only a few devices, a manual adaptation of the Linux kernel is usually out of the question for us. The effort involved is too great and the consequences for the further life cycle of a product are too unclear. Therefore, the operating system - often a Raspberry Pi OS - should be used in its factory state and without major adjustments, if possible.

Two modems have emerged for us that work “out of the box” in combination with the current Raspberry Pi OS on Debian 11 “Bullseye” basis (kernel 6.1):

Waveshare 4 Inch display does not work with IO BASE MODULE B

Because we had to find out the painful way: The Waveshare IO BASE Module B for the Raspberry Pi CM4 module does not work with the 4" DSI Touch Display from Waveshare - at least not as long as you use a BASE IO board revision < 4. Only from board version 4 the higher performance DSI1 interface is used instead of the DSI0 interface of the Raspberry CM4 by the IO Base Board.

Qt 5.15.2 with WebEngine (Chromium) - Limit RAM usage to avoid crashes

When compiling Qt 5.15.2 from the official open source sources, we encountered a problem in combination with our build server: The build process was interrupted while compiling the Chromium-based “WebEngine” component with initially mysterious error messages. A look at the kernel log using dmesg -w then quickly revealed that the so-called OOM killer of the Linux kernel had struck. Apparently the RAM consumption of the build process was so memory-intensive that the process had to be aborted to keep the operating system running.
Mastodon