One idea I had for libreCMC was to run a Layer 2 OpenVPN tunnel with both server and client being libreCMC nodes.For the uninitiated: a Layer 2 OpenVPN tunnel allows someone on the client network to see the server network, as though he was directly plugged into the server network with an Ethernet cable. In other words, it allows you to remote into your home or work network from anywhere on the Internet.
“Layer 2” means that the traffic communicated by the VPN is straight from the Data Link layer (layer 2 in the OSI model), which is to say that the VPN (Virtual Private Network) becomes a long-distance Ethernet switch. OpenVPN setups usually are done in Layer 3 mode, which is on the IP layer (i.e., long-distance router). In my particular use case, I wanted a Layer 2 VPN because I wanted my customer to have a more direct access to the subnet, which I figured would make it simpler to access printers and file shares and such. If I had realized how little community support is available for Layer 2 OpenVPN, I might have chose a Layer 3 VPN instead. There also are a few other good reasons to prefer Layer 3 VPN. But at least I can say I’ve learned a little more than the average Joe in the process.
My idea was to set up one libreCMC node (a TPE-R1100) on the work LAN as the OpenVPN server, and then another libreCMC node (a GL-AR150) would be the OpenVPN client, which could be pocketed for business trips and such. So, someone with the client node would simply need to know the Wi-Fi password and then have access to the resources on the work LAN.
This has the advantage of simplicity as then I don’t need to run or configure special VPN software on the customer’s devices. Of course, it raises some obvious security concerns; but at least if the client node is stolen, that is pretty obvious and I could shut down the VPN or cut off that client’s access.
It was very challenging to figure out how to generate the certs and keys and such, and the put the right OpenVPN settings on both server and client. It was a slow process of many hours, tweaking the configuration settings, reading the logs for errors, and then looking at the the OpenVPN manual page for hints at what I must have set wrong. As I mentioned, there is unfortunately very little community help for folks wanting to set up a Layer 2 VPN, but the manual page gives very good descriptions of the configuration options. It is important that client and server have compatible settings.
In the most recent troubleshooting step, I figured out from the logs that the server and client were in fact communicating data properly (I could see MAC addresses from the client side showing up in the server logs) but for some reason I still could not send ICMP pings or HTTP traffic across the VPN. I discovered that actually it was a problem not with the VPN tunnel, but rather that my client interface configuration was somehow not allowing data to flow properly from my client bridge interface to the TAP VPN interface. (More on this later.)
I figured out a way to fix this problem, and the fix worked, and I was able to ping across the VPN tunnel both ways, as well as access an HTTP server. That was very encouraging. However, in the processes of committing the final settings, I accidentally set the the network setting wrong, and cut off all network access to the client node (“soft brick”). That was rather annoying. Fortunately though, I saved the working configuration, so tomorrow I should be able to reset the node and reload the configuration, if I am not too busy.
Once I’ve fixed my setup, I’m planning to finish the official documentation I have been working on, and also post more about it here on the blog.
The Libre Hacker 