SSH into RT-AC68U/RT-AC86U how to make files persist?

[BosseSwede]

I want to manually configure advanced options for the OpenVPN server on my two ASUS routers.
But when I log on to the devices via SSH it turns out that even /etc is symlinked into /tmp/etc, which suggests that the file system is temporary only (in RAM).
How can I then modify files there and have them survive a reboot or power loss?
Is there a way to put them into a safe place so they won't be lost?

 

[ColinTaylor]

You configure it through the GUI using the Custom Configuration box.

 

[BosseSwede]

So what you are saying is that I should not configure on the command line but through the GUI?
Can I enter whatever I like as custom config in that box?
For example I need to create a user profile, say "RouterCabin" and this user shall need a ccd entry (client config dir entry) like this in a file named RouterCabin in the ccd dir:

iroute 192.168.117.0 255.255.255.0

in order to route back through the tunnel from the server side LAN to the client LAN.
I know how to do all that via the command line (which I have been using many years when configuring OpenVPN servers).

GUI is really a PITA since they often do not translate to common sense,,
For example what does this mean:

It seems like by saying Yes to this dialog, then the use of name/password is NOT required? Or is it the opposite? Extremely confusing.
And what does it do to the server config file?

I would like to test using the built-in VPN server but I need to be able to understand its configuration and that is only possible if I can see the config file itself...

And how do I add new users, which should need cert authentication but no password. The only option given when adding users is to enter the Common Name (I assume) and a password, even though one has set No to the Username/Password Auth. only question. Soo very confusing.

After I set it up as well as I could understand it in the GUI the resulting /etc/openvpn/server1/config.ovpn file looked like this:

# Automatically generated configuration

# Tunnel options
proto udp
multihome
port 1194
dev tun21
sndbuf 0
rcvbuf 0
keepalive 15 60
daemon vpnserver1
verb 3
status-version 2
status status 10
comp-lzo adaptive
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn

# Server Mode
server 10.251.13.0 255.255.255.0
client-config-dir ccd
duplicate-cn
push "route 192.168.119.0 255.255.255.0 vpn_gateway 500"

# Data Channel Encryption Options
auth SHA1
cipher AES-256-CBC

# TLS Mode Options
ca ca.crt
dh dh.pem
cert server.crt
key server.key

# Custom Configuration

 

[eibgrad]

For the purposes of site-to-site (i.e., where you need to identify to the *server* the network(s) available behind a given OpenVPN client), you use the Manage Client-Specific Options section of the OpenVPN server. You add entries that uniquely identify that OpenVPN client based on the CN (Common Name) of its client cert. If you use the auto-generated client cert (which most ppl do), the CN is named 'client' (without the quotes). Using this technique, the router will *automaticially* create a file by that name (client) in the CCD directory, add an iroute directive to it, add a route directive to the config, etc. IOW, it does all the things YOU have been doing (apparently) manually for all these years. It actually makes configuration of site-to-site much simpler.

As far as username/password, that's a completely separate issue.

For reasons of simplicity, the router only generates *one* client cert (w/ the CN of 'client') to be shared by *all* OpenVPN clients. Therefore, it becomes difficult to distinguish one OpenVPN client from another for the purposes of site-to-site, since all have the same CN. If you happen to be using username/password, what you can do is add the following to the server's custom config field.

username-as-common-name

NOW, instead of having to specify the CN in the Manage Client-Specific Section, you can specify the username! IOW, each user (for the purposes of site-to-site) is disambiguated based on the username, NOT the CN.

All that said, in the real world, anyone managing a serious site-to-site configuration would never depend on one shared client cert. Instead, each would be provided their own unique cert, each w/ an equally unique CN. And you wouldn't need or even want to use username/passwords at that point. It's superfluous. That would be like configuring SSH to use private/public keypairs, yet still requiring passwords. But creating all your own client certs (and keys) is a hassle. It means YOU have to use EASY-RSA outside the router on some Linux or Windows PC, import them to the router, yada yada. So many ppl don't bother to do it this way. But IMO, they SHOULD!

 

[BosseSwede]

OK, I get it...
Seems like I may as well continue using my Linux server for OpenVPN access like I have successfully configured it yesterday.

On that I have a script I wrote myself several years ago where the client ovpn files are created (each given a separate CN of course) and I have set up the ccd system so the needed iroute can be set for exactly one client (the remote router). Easy admin.

The reasons I wanted to explore the use of the router's built-in VPN are:
- System simplicity since then only the routers themselves are involved
- Possibly speed of transfers since a detour through the Linux server is avoided

On the speed issue I do not really know if the Linux server might be slower or faster than the router on the crypto side, but it might be a minor issue since I usually do not transfer big data between the two LAN's. I have configured the client to use its own gateway for general Internet traffic. Both fiber interfaces are 250/250 Mbit/s.

OTOH I have seen that the OpenVPN version in the router is quite old, version 2.3 whereas Ubuntu repositories supply version 2.4.7 currently.
When I talk to the OpenVPN community they seem to suggest that 2.3 should not be used any longer...

 

[eibgrad]

OK, I get it...
Seems like I may as well continue using my Linux server for OpenVPN access like I have successfully configured it yesterday.

I agree. Given you previously reported it was working just fine, using the router doesn't really provide much more benefit. In fact, the router is KNOWN to not be nearly as efficient and fast as an actual desktop platform for OpenVPN. What the router offers (at least for most ppl) is convenience. But that convenience comes at a price, and having to be bound to one shared client cert and key is one of them. As I said, for serious, real world usage, the default OpenVPN server configuration, at least when it comes to site-to-site, and where you have more than one OpenVPN client, is far from ideal. You can *make* it work if you're willing to do all the EASY-RSA work yourself, but if you've already done that on some standalone PC or VM, why bother?

On that I have a script I wrote myself several years ago where the client ovpn files are created (each given a separate CN of course) and I have set up the ccd system so the needed iroute can be set for exactly one client (the remote router). Easy admin.

The reasons I wanted to explore the use of the router's built-in VPN are:
- System simplicity since then only the routers themselves are involved
- Possibly speed of transfers since a detour through the Linux server is avoided

On the speed issue I do not really know if the Linux server might be slower or faster than the router on the crypto side, but it might be a minor issue since I usually do not transfer big data between the two LAN's. I have configured the client to use its own gateway for general Internet traffic. Both fiber interfaces are 250/250 Mbit/s.

OTOH I have seen that the OpenVPN version in the router is quite old, version 2.3 whereas Ubuntu repositories supply version 2.4.7 currently.
When I talk to the OpenVPN community they seem to suggest that 2.3 should not be used any longer...

You can always try both the router and Linux system to compare throughput. Ultimately it may not matter if your internet bandwidth is severely limited on the up side (i.e., asymmetric) for either ISP.

FWIW, there is one other advantage of NOT using the router for the OpenVPN server. When using both the OpenVPN server *and* client (e.g., to some commercial OpenVPN provider) at the same time, you won't be able to reach the OpenVPN server if the router has bound *all* traffic to the OpenVPN client. And that's because the replies from clients of that OpenVPN server get routed over the router's OpenVPN client too! The required fix is usually to enable policy routing on the OpenVPN client so that it removes the router itself from the VPN. But that can sometimes lead to other problems, such as DNS leaks. So pushing the server to some other internal device like the Linux PC/VM avoids that problem, assuming that device itself is NOT being routed through the router's OpenVPN client.

Yes, it all gets very complicated. That's why it's difficult to make rock-solid recommendations to users based on so little information. Each user's need sare unique and may require a different approach. The trick is learning all these little details so YOU can make wise choices. But that takes years of experience, and hence why so many have problems getting things right.

 

[BosseSwede]

Thanks for your help and explanations! Much appreciated!