Birthday Hint

Shameless plug for my birthday coming up next month…


I’m eager to own one or more of these GL-AR300M units, which sport dual antennas, a 300MHz CPU, and 128 MB NAND flash, for my libreCMC experiments. With that much CPU and persistent memory, it can be treated more like a pocket pc than a pocket Wi-Fi router. The units are not very expensive (under $40) though for the cheap shipping you have to figure in about 3 weeks of shipping time.

Builds with Flock Fix

My most recent builds have a bug in the configuration due to missing busybox flock program, which generates annoying messages in the log. Here are new builds:

  • libreCMC v1.4.2 commit 1652ef7 source
    • magnet:?xt=urn:btih:39bb40c25ddffbb8c3eeefdd7e685a29facf506b&dn=librecmc-v1.4.2-c%5F1652ef7.tar.gz
  • libreCMC v1.4.2 commit 1652ef7 TPE-R1100 Build
    • magnet:?xt=urn:btih:3aecd53e10ffdf76809ba86522782fa1db9defd9&dn=librecmc-v1.4.2-c%5F1652ef7-flock-ar71xx-generic-tpe-r1100-squashfs-sysupgrade.bin
  • libreCMC v1.4.2 commit 1652ef7 GL-AR150 Build
    • magnet:?xt=urn:btih:d3f93eb8bb6dd37dbefa2062caccfb72fd1040ce&dn=librecmc-v1.4.2-c%5F1652ef7-flock-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin

The GL-AR300M build will be done later.

Layer 2 VPN: It’s ALIVE!

My libreCMC to libreCMC Layer 2 OpenVPN connection worked successfully in a test from home -> work LAN. A few of the cooler looking log snippets:

openvpn(asi_eth_client)[821]: UDP link local: (not bound)
openvpn(asi_eth_client)[821]: UDP link remote: [AF_INET]<snip>:1194
openvpn(asi_eth_client)[821]: TLS: Initial packet from [AF_INET]<snip>:1194, sid=<snip> <snip>
openvpn(asi_eth_client)[821]: VERIFY OK: depth=1, C=US, ST=AK, L=Fairbanks, O=Alaska Satellite Internet, OU=Solutions, CN=Alaska Satellite Internet CA, name=ASICA, emailAddress=<snip>
openvpn(asi_eth_client)[821]: VERIFY KU OK
openvpn(asi_eth_client)[821]: Validating certificate extended key usage
openvpn(asi_eth_client)[821]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
openvpn(asi_eth_client)[821]: VERIFY EKU OK
openvpn(asi_eth_client)[821]: VERIFY OK: depth=0, C=US, ST=AK, L=Fairbanks, O=Alaska Satellite Internet, OU=Solutions, CN=myvpn, name=myvpn, emailAddress=<snip>
openvpn(asi_eth_client)[821]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
openvpn(asi_eth_client)[821]: [myvpn] Peer Connection Initiated with [AF_INET]<snip>:1194
openvpn(asi_eth_client)[821]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
openvpn(asi_eth_client)[821]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
openvpn(asi_eth_client)[821]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Some snippets from tcpdump, showing the traffic being passed back and forth along the tunnel:

05:24:31.717536 IP <snip> > UDP, length 382
05:24:31.717647 IP <snip> > UDP, length 81
05:24:31.721769 IP <snip> > UDP, length 188
05:24:31.722641 IP > <snip> UDP, length 163
05:24:31.739124 IP <snip> > UDP, length 105
05:24:31.800892 ARP, Request who-has tell, length 46
05:24:31.927072 IP <snip> > UDP, length 393
05:24:31.931171 IP > <snip> UDP, length 163
05:24:32.205518 IP <snip> > UDP, length 398
05:24:32.209665 IP > <snip> UDP, length 163
05:24:32.482088 IP <snip> > UDP, length 130

Screen shot of the interface stats:

Screenshot from 2018-02-26 20-30-28

I disabled the LAN ethernet and password protected the Wi-Fi to make it a little more challenging for a passerby to casually “plug in” to the exposed VPN. Once I connected to the Wi-Fi, I was able to access my work file share, printer interface, and backup storage system.

I’m going to submit my config info to the official libreCMC docs.

GL-AR300M NAND Build

Please see the previous post for details.

  • libreCMC v1.4.2 commit 1652ef7 source
    • magnet:?xt=urn:btih:39bb40c25ddffbb8c3eeefdd7e685a29facf506b&dn=librecmc-v1.4.2-c%5F1652ef7.tar.gz
  • libreCMC v1.4.2 commit 1652ef7 GL-AR300M NAND build
    • magnet:?xt=urn:btih:9444f30d781c2e6a7646ba30042b9603257b578c&dn=librecmc-v1.4.2-c%5F1652ef7-ar71xx-nand-gl-ar300m-ubi-factory.img

Firmware Builds: v1.4.2 Commit 1652ef7

I made some builds of a slightly newer commit of the v1.4.2 branch. The reason was to get an additional security patch, and also to get a few more utilities and networking tools into the build.

These builds can be download through the Transmission BitTorrent client, which uses Distributed Hash Tables (DHT). You have to select File >> Open URL… and then paste in the magnet link.

  • libreCMC v1.4.2 commit 1652ef7 source
    • magnet:?xt=urn:btih:39bb40c25ddffbb8c3eeefdd7e685a29facf506b&dn=librecmc-v1.4.2-c%5F1652ef7.tar.gz
  • libreCMC v1.4.2 commit 1652ef7 TPE-R1100 Build
    • magnet:?xt=urn:btih:80ddaac008cf57a190ac7be2cb25c95a4ecf67f3&dn=librecmc-v1.4.2-c%5F1652ef7-ar71xx-generic-tpe-r1100-squashfs-sysupgrade.bin
  • libreCMC v1.4.2 commit 1652ef7 GL-AR150 Build
    • magnet:?xt=urn:btih:08fe7a21073a7622c65d52b60877d792cda78ec8&dn=librecmc-v1.4.2-c%5F1652ef7-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin

I haven’t started the GL-AR300M build yet.

Non-default features:

  • Luci + OpenSSL (instead of mbedtls)
  • Nano, Vim, and Zile editors
  • Default and Material LuCi theme
  • openvpn-openssl, openvpn-easy-rsa, luci-app-openvpn
  • nmap-ssl, nping, wget (full version) and tcpdump networking utilities

This bumped the image sizes up to 7.6 MB.

The patched vulnerability was CVE 2018-5332.

OpenVPN packages are included because of my OpenVPN projects. I find the nmap, nping, and tcpdump utilities useful when trying to troubleshoot an advanced network configuration issue on the router, such as when I couldn’t figure out why my OpenVPN tunnel didn’t seem to be working.


Layer 2 OpenVPN Endpoints

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.