In both, an sftp server is installed, in the version corresponding to each openwrt. It is intended set a root directory to limit access to certain subdirectories of the file system using the ChrootDirectory parameter. In version 18.06.2 the use of this parameter gives an error that I cannot solve. Have a router with OpenWrt installed? Why not use it for something else? As a OpenWrt PXE server for booting your favorite Linux/UNIX distro. Possibilities with a PXE.
- OpenSSH SFTP server.
- Installed size:
- libc, libssp
- aarch64_armv8-a, arc_arc700, arc_archs, arm_arm1176jzf-s_vfp, arm_arm926ej-s, arm_cortex-a15_neon-vfpv4, arm_cortex-a5, arm_cortex-a53_neon-vfpv4, arm_cortex-a7_neon-vfpv4, arm_cortex-a8_vfpv3, arm_cortex-a9, arm_cortex-a9_neon, arm_cortex-a9_vfpv3, arm_fa526, arm_mpcore, arm_mpcore_vfp, arm_xscale, armeb_xscale, i386_geode, i386_i486, i386_pentium4, mips64_octeon, mips_24kc, mips_mips32, mipsel_24kc, mipsel_74kc, mipsel_mips32, powerpc_464fp, powerpc_8540, x86_64
- LEDE Release:
- File size:
- BSD ISC
- Peter Wagner
- Bug report:
- Bug reports
- Source code:
This guide reflects my personal notes for personal use; it expects you to have an up-and-running OpenWRT firmware on your router, an existing dynamic DNS service available as well as know your way around Terminal i.e. CLI and SSH. These instructions below are published for people to compare notes and understand the process like I did. Kindly understand that I cannot be held responsible for any mistakes or malfunctions on your side.
I recently decided to install a secondary OpenVPN server on my Asus RT-58U router, as a backup gateway to my home network.
1. Package Installation
To set up and configure an OpenVPN server so we can connect to our home’s local network, we need to first install the following packages:
Additionally, as my preferred editor is
nano and it doesn’t come with OpenWRT, it’s a good idea to install that one, too:
So we have first updated/refreshed the latest available packages from the source repository; then we installed the 4 needed packages; finally, we just restarted the router’s web server daemon.
Note: In case there is a need to re-install a package and its dependencies, use the
2. Generating Necessary Keys
Next, we need to generate the required server keys and certificates using
easy-rsa. It is recommended that we move our
easy-rsa files from the default location so that we don’t accidentally overwrite those in case of a system or firmware update.
For a fresh installation on an OpenWRT firmware:
For an existing installation after an OpenWRT firmware update:
The idea here is that we create an independent folder to store all of our keys instead of the
/etc/easy-rsa/ folder, as the latter does not survive a firmware update; we only need to link symbolically this original (and needed) folder
/etc/easy-rsa/ to point to our own folder under
/etc/config/ that does survive a firmware update.
Now, we must generate the certificates for the server and client(s). We need to start by editing a few lines in the
/etc/easy-rsa/vars file and enable stronger 2048-bit encryption. Edit this file with e.g.
nano and change the following variables with your own details:
Note: The first parameter
EASYRSA_REQ_COUNTRY requires a 2-digit country code like GR, FR, DE, IT, NL, UK, DK etc.
Now uncomment, further down, the following line by removing
# so it appears like this:
Next, we generate the “Diffie-Hellman” key agreement parameters, our “Certificate Authority” and pre-shared key pairs, signed locally. Run each command at a time by first moving to the needed directory.
We first set the needed configuration parameters, by entering these on the CLI:
Now, we remove and re-initialise the PKI directory. If you are curious, you can do
ls -la ./pki before and after this procedure, to check the contents. Simply run:
Now let’s generate the “Diffie-Hellman” parameters (will take some minutes) and create a new “Certificate Authority” certificate, by validating their creation via
Note: You may have noticed that we selected to not have a password set, by using
Next, we need to generate the server keys and the client keys, both signed locally:
Openwrt Openssh-sftp-server Config
Finally, we need to generate the TLS pre-shared keys (PSK) for our installation:
Note: Remember that
EASYRSA_PKI was defined earlier.
3. Set Firewall Parameters
Next, we need to define and change the firewall parameters. For this server installation, we consider the VPN network as private and we assign the VPN interface directly to our LAN zone to minimise firewall setup. Then, we permit (i.e. open) access to the VPN server from WAN (Wide Area Network) zone.
First we set some more needed configuration parameters, such as the firewall port and protocol, by entering these on the CLI:
Note: Despite the standard VPN port being 1194, here we set it to 1193 as this VPN server installation is a backup VPN (since one exists already on a NAS server running OpenMediaVault, in the same home network). For a single VPN server in a home network, change to default value 1194 where needed.
Run the following two multi-line commands on CLI:
Note: Again, remember that
OVPN_PROTO were defined earlier. Now let’s verify the new firewall entries that we saved above, by running:
In the meantime, we also need to check if packet forwarding is enabled; it should be by default. A result “1” denotes that it is active:
4. Create OpenVPN Server Instance
Now, we must create our OpenVPN instance (named “asus_server”) that will be soon visible in the OpenWRT interface (by going to menu VPN and clicking on OpenVPN page):
Finally, we need to define the settings to be “pushed” to clients that will connect, reflecting the above parameters:
So, what have we achieved with the commands above? In the first part, we perform the following server operations:
Similarly, in the second part, we define the same settings to be communicated to the client as needed:
(*) Extremely useful if the client’s local network cannot be trusted e.g. airports, workplace or coffee shops.
We can now restart the service to apply our changes:
To view the above settings at any moment:
We need to be sure that the OpenVPN server is enabled and has started:
At any moment, we can check the logs for a successful server initialization and the respective service is running as expected:
A likely output from these logs above indicating success, would be:
5. Creating Client Configuration File
With the OpenVPN server now in place and running, we can finally create the client’s configuration
.ovpn file to be used with the remote client computer. In a plain-text file called for example
Asus.ovpn enter the parameters found below, using your favourite editor on your computer. Below is a manual process that will require some copying and pasting from your Terminal window.
We are now ready to use VPN client tools such as Tunnelblick on macOS. As we have not defined a user or password, connecting to our router will simply need to run the VPN client software and launch our configuration.
IMPORTANT NOTE: You need to replace the
YOUR-DOMAIN-NAME entry found above with either your fixed WAN IP address if you have one, or a dynamic DNS name, such as those kindly provided by DuckDNS. This is an absolutely needed parameter as the client computer must know where to connect, obviously!
N.B. For those wondering, like myself, as to why there is no
<tls-auth> section in the above configuration, according to the OpenVPN – Getting Started / How-To page:
Please note that you cannot use “–tls-crypt” and “–tls-auth” options at the same time […] Using “tls-crypt” also does not need to care about the KEYDIR as it is handled automatically.
Sources & Further Reading
The knowledge acquired and the guide above would not have been possible without the following sources: