Back in September 2016 we had a long troubleshooting session with Securifi specialists trying to make Almond+ connect to a remote VPN server. Results: a pdf with instructions to manually set up connection using SSH console and a promise to address the problem in a future firmware, which so far didn't happen. I've spent today trying to set up at least some scripts to quickly turn VPN client on or off; as a side effect, I realized there are actually around 3 separate bugs in Almond's OpenVPN client implementation that need addressing (Securifi specialists probably figured that out back in September, but they weren't too open about their findings):
1)OpenVPN crashes immediately on launch because of inline certificate error. This happens if some of the certificate fields are left empty (if they are not required or provided by your VPN service). As a result, the client.ovpn config file will contain empty blocks like <cert> </cert>. Workaround: after pressing "save>connect>disconnect" manually delete empty intermediary certificate files (i.e. client.cacert). Deleting faulty blocks in client.ovpn won't help as it is regenerated when you press "connect"
2)Routing settings are not applied properly. When you press "connect", Almond changes routing /etc/config/network and /etc/config/ntpclient. These changes are more or less sufficient (see bug 3), but they are not applied fully. Reboot helps - but it's not an option for a web interface. Some way of reloading everything related to this routing must be found. If we keep these changes, reboot, relaunch openvpn client, it will finally work, except
3)Broken DNS. DNS settings are successfully received from VPN service, as evidenced by openvpn logs, but they are lost somewhere on the way towards LAN. Workaround: set up google DNS (8.8.8.8 8.8.4.4) manually either on each client, or in OpenWRT>Network>Interfaces>LAN.
What this means for users: you can make OpenVPN client work manually, via command line (or you can write a couple shell scripts). The attached pdf from Securifi has the right idea, but does a few unnecessary things. Follow these instructions, but for /etc/config/network use
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'wan'
option 'broadcast' '0'
option 'ifname' 'tun1'
option 'proto' 'none'
config 'interface' 'lan'
option 'ifname' 'eth1'
option 'type' 'bridge'
option 'proto' 'static'
option 'ipaddr' '10.10.10.254'
option 'netmask' '255.255.255.0'
option 'bcast' '10.10.10.255'
option 'dns' '8.8.8.8 8.8.4.4'
config 'interface' 'wan1'
option 'proto' 'dhcp'
option 'ifname' 'eth0'
and for /etc/config/ntpclient use
config 'ntpserver'
option 'hostname' '0.pool.ntp.org'
option 'port' '123'
config 'ntpserver'
option 'hostname' '1.pool.ntp.org'
option 'port' '123'
config 'ntpserver'
option 'hostname' '2.pool.ntp.org'
option 'port' '123'
config 'ntpserver'
option 'hostname' '3.pool.ntp.org'
option 'port' '123'
config 'ntpdrift'
option 'freq' '0'
config 'ntpclient'
option 'interval' '600'
option 'interface' 'wan1'
This is almost exactly what the OpenWRT-side script would've done, except for an additional DNS setting. Also, wait about 5 minutes after router reboots for connection to actually start working.
And Securifi: I can't stress this enough, you need to finally fix this. It's a basic feature which was supposed to be available since day 1.