Update 6/2/2019 – EdgeOS is now on version 2.0.3 which brings an updated OpenVPN client. After copying the openVPN configuration file to the router and running the commands to set up the virtual tunnel interface, I rebooted the router and enabled the interface from the web UI. It came up immediately and got an IP address.
This will allow you to connect your EdgeRouter to an OpenVPN server to route network traffic for all your devices through the VPN tunnel.
The EdgeRouter operating system runs a very old version of OpenVPN and doesn’t support the latest configuration directives and TLS cipher suites.
I had to:
- Comment out the “tls-version-min” option in the .ovpn configuration on the router
- On the client AND the server configurations, change the tls-cipher to TLS-DHE-RSA-WITH-AES-128-CBC-SHA
- Generate the .ovpn on the server, download it, and copy it (using SCP) to the router to the path /config/.
- SSH into the router and run the following, replacing the file name with your actual ovpn file:
configure set interfaces openvpn vtun0 config-file /config/vpn-client1.ovpn commit save exit
Originally, I got an error here – “Failed to start OpenVPN tunnel” – when I had the tls-version-min present in the configuration. You can troubleshoot this by going to the /var/log/messages – or you can probably use the Log Viewer in the router’s web GUI.
Now that OpenVPN would actually start, the next problem was getting the tunnel established. OpenVPN would repeatedly fail and reconnect, with this error (among many others) in the log:
Sun Mar 11 16:09:46 2018 TLS_ERROR: BIO read tls_read_plaintext error: error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers available
This was because the cipher configured on my server was not supported on the EdgeRouter.
Edit the /etc/openvpn/server.conf and use the cipher above. Then change this in your client configuration if you haven’t already. You should probably set the tls-version-min to 1.0 on the server. Yes, this means downgrading the security. Also, any other clients you’ve configured will not work anymore because their configuration will be using the old cipher suite.
Once you’ve done all that, the tunnel SHOULD come up now and the interface should be connected/assigned an IP address in the VPN subnet range.
However, traffic still wasn’t being sent through the VPN. To fix this, I logged into the GUI, went to Firewall/NAT tab, then the NAT sub-tab. There should be one rule called “masquerade for WAN”. Click Actions > Config and change the Outbound Interface to vtun0, then click Save. That should do the trick. Now your traffic should be going through the VPN; go to a site like whatismyip.com to confirm it.
Optional: if your VPN tunnel goes down for whatever reason, you won’t be able to access the internet at all. You can set up another NAT rule as #2 to use eth0; this will only be used if the VPN is down.
Click Add Source NAT Rule, configure the options as follows (ignore the other options listed; they don’t need to be configured), then save the rule and click Save Rule Order. (Not sure if that matters, but it couldn’t hurt.)