Raspberry Pi, VLAN, and Docker

by Rian

A bit of rant while exploring different routes to host multiple OpenVPN clients on a single Raspberry Pi device. If you are a subscriber to paid VPN services, you would immediately know most services offer multiple server destinations. And you would also know, by following the previous post, that the said how-to only allows one connection to be made on one Pi board. While Pi is underpowered in terms of performance, it’s certainly enough to support multiple OpenVPN clients. That’s how the train wreck of a DIY project started.

Lack of documentations is probably the true enemy of all DIY projects, and not knowing their documentation is lacking is just worse. This is what happens, or what happened to me, as I was venturing the uncharted territory. It seemed to make sense to build one physical device that will run multiple VPN clients simultaneously. What I didn’t consider was at least three things: one, the project was to be done on Raspberry Pi, which is powered by ARM chip, two, a VPN client for docker (for scalability and portability) was to be used, which was open-source, and three, I was going to use a VPN provider that offers both WireGuard and OpenVPN. Notice any problems? Because looking back, that three bullet points weren’t points, they were red flags.

Though Raspberry Pi is a popular platform to start any DIY projects, it remains a minority —albeit how minor, I don’t know— in Linux community. Both VPN provider and the VPN client project in-question try to work with Pi, but their documentations were telling me something else: outdated, or supported with limitations, or supported with poor performance. WireGuard was one example. On documentations from the client side, my provider was on the supported WireGuard operator list. Turns out, that is not the official word from the provider, as any documentations from the provider was strictly limited to OpenVPN. Combing through documentations only to find out inconsistencies was a bit jarring.

Documentations on open source projects, especially the ones without the attention of a mindful writer, are often looking like a CV —they say they can do all sorts of things. There were several hurdles just reading the documentations. It lacked coherent definition of variables, and because this is a community effort, pages were written and edited with anecdotal information, not by what the actual code says. I lost my hope when the VPN client lacked proper documentations on how to solve one of the most commonly occurring problems that even had a dedicated page. It was simply inconsistent through and through.

When it boils down to VPN providers, some are definitely better than the others, but there is no guarantee things will “work” only because there is a documentation related to the subject. One of the odd threads I found was that there are VPN providers that have one connection per device policy. And if I understand the idea correctly, under that policy, the user is not allowed to NAT the VPN connection. Of course, there are other baggages to consider as well, some providers don’t open all the ports, let alone allow all the packets, for the purpose of stopping certain abusive behaviors. Are those policies easily accessible? Frankly, I had better luck finding out about them with 30-day trials and VPN reviews.

My experience is only anecdotal; I’m positive it is possible to run multiple VPN connections on one device and serve multiple VLANs. After all, there are many ways to achieve the same goal. What ultimately made me to rethink my project was that it felt far more manageable to deploy multiple Pi routers then to deploy multiples of my unchecked work on a single Pi, not to mention this will keep one-armed routers separated physically. It wasn’t the most successful endeavor, but I did learn that just because there is good-looking open source software, doesn’t mean it will magically adapt to my DIY projects.