maxbraketorque
Very Senior Member
I have been experimenting with bi-directional LAN-to-LAN OpenVPN implementations for a few weeks now. I figured out the basics by working my way through this thread:
https://www.snbforums.com/threads/u...o-asus-routers-via-openvpn-in-tun-mode.54868/
I already had a working OpenVPN server that was not operating in bi-directional mode, so the challenge was figuring out what was different than a standard OpenVPN server setup. I eventually realized that for some configs, there was very little difference in the setup, so I decided to create a thread to help simplify the bi-direction setup process for people who already have a working OpenVPN server.
But before I get into the differences, I'd like to first discuss selecting which site is the OpenVPN server and which is the client. I need a bi-directional VPN implementation to create a permanent LAN-to-LAN link where LAN-to-LAN data transfers and communication can be initiated from either LAN. This is a different need than simply wanting to access a home network from a remote location, such as while on travel. In particular, I want IP cameras at the remote sites to send their recordings to my home NAS, and I want to be able to manage those IP cameras from my home network. I spend relatively little time at the remote sites, so for these needs, I think its preferable to make the remote site the OpenVPN server and make the home site the client. That way, I can initiate or terminate the VPN tunnel from home. A limitation of using these server/client roles with the OEM firmware is that the client router can only connect to one OpenVPN server at a time. So multiple remote LANs cannot be linked to the home LAN using these client/server roles with the OEM firmware. There are two ways to get around this when multiple remote LANs need to be connected to the home network.
For the OEM firmware, its possible to get around this by switching the server/client roles, i.e., make the home network the server, and make the remote sites the clients. The main challenge with the reversed role is control over the link between the home and remote sites. The OpenVPN client implementation can be set up to automatically reconnect after a power cycle, but if for some reason there is a need to stop and/or restart a connection, it requires having another way to get into the remote network to do this. One means is to temporarily enable access to the remote router via the web GUI from the internet, but this is discouraged. Another means is to have a device at the remote site that has RDC or some other network access server installed on it.
The other option for having multiple remote sites connected to the home network is to use Merlin firmware on the home router. Merlin firmware allows up to six OpenVPN client sessions to run at once. Merlin firmware also includes the current implementation of OpenVPN, there are more options in server and client setup, and it allows for a more efficient cipher to be used (GCM) if Merlin firmware is installed on the home and remote routers.
I eventually settled on installing Merlin firmware on all the routers along with setting up the remote sites to act as OpenVPN servers.
ok, so what's different than a typical ASUS router OpenVPN configuration? I am covering this so that people who already have an OpenVPN server can quickly transition to the bi-directional mode. These changes are specific to the situation where the home router is acting as the OpenVPN client. Here's what needs to be changed:
- The LAN IP address range (in the "LAN" setting) of all the routers being linked needs to be different to prevent routing conflicts. I've been sticking to 192.168.XXX.YYY with XXX being different for each router but do whatever you want as long as you are not producing routing conflicts and are using private IP addresses.
- Change the OpenVPN server subnet address on each router (in OpenVPN server Advanced settings). This is also needed to prevent routing conflicts. If you only use the client router as an OpenVPN client (with the OpenVPN server on that router disabled), and if you only have one remote site, then changing the OpenVPN server Subnet address isn't necessary. The OpenVPN server Subnet address needs to be different at each site. My way of selecting a VPN server subnet address is as follows. If the router LAN IP address for the server (listed in the *LAN* settings for the router) is WWW.XXX.YYY.ZZZ (where WWW.XXX is not 10.8), then I set the server VPN Subnet to 10.8.YYY.0.
- In the OpenVPN server "Advanced" setting, enable "Manage Client-Specific Options". Then enable "Allow Client <-> Client".
- Add an entry to the "Allowed Clients" table for the client that will be connecting. There are three ways to approach setting up this table, and this is where this process can become more complicated. The three options are related to a trade-off between OpenVPN security and ease of bi-directional setup. The first column in the Allowed Clients table is a means to identify a client to set up the appropriate routing. In the situation where standard OpenVPN security measures are used, a client Common Name is entered. This name is generated when the client OpenVPN certificate is created. However, there is no means to specify a unique client Common Name when using the client certificate generation tool built into the OEM OpenVPN implementation. The built-in ASUS tool sets the client Common Name to "client". Being stuck with "client" as the Common Name is fine if the server is only going to have a single connection from a particular site. However, if there is intent to have multiple clients (e.g., LAN-to-LAN as well as say computer-to-LAN), then this option breaks because each client connecting to the OpenVPN server needs a unique Common Name for bi-directional implementation. If all clients have the same Common Name ("client"), then when a second client tries to connect, the first one gets booted, and a battle for the connection ensues. One way to get around this is to move away from using Common Name to identify the client, but doing this requires reducing OpenVPN security. The other way to get around the limitation of the built-in client certification generation tool is to create your own certificates using Easy-RSA. Here is the scoop on each method along with their limitations:
1) Do like the OP of the Guide thread did where he reduced login security by enabling the option, "Username/Password Auth. Only". This does away with client/server certificate authentication which is part of the standard security protocol. It is generally not recommended, although to be honest, I'm not sure how much of a security issue it is. When this option is enabled, the heading of the first column in the Allowed Clients table becomes, "username", and then usernames from the list created on the General page of the OpenVPN server setup are used. With this method, its possible to easily have multiple clients connected to the OpenVPN server, but at reduced security.
2) Do not enable "Username/Password Auth. Only", and use "client" as the Common Name. As already discussed, standard security is maintained, and this setup works fine if there is only ever going to be a single connection to the VPN server. It doesn't work for multiple clients connecting to the server in bi-directional mode.
3) Generate your own certificates and keys using Easy-RSA. This is really not hard, but it felt rather involved the first time I did it. All necessary certificates and supporting items for the client and server have to be generated and inserted into the client and server configurations. Creating these items using Easy-RSA can be done a few different ways. The Merlin firmware install includes the capability to separately run Easy-RSA on the router command line. However it requires some knowledge of command line, and it requires a USB drive to be installed on the server router. The other means is to run the Windows, Mac, Unix, etc. versions of Easy-RSA. There are how-to guides on the internet for any of these Easy-RSA methods. In particular, the how-to for the Merlin-based method is here:
https://github.com/RMerl/asuswrt-merlin/wiki/Generating-OpenVPN-keys-using-Easy-RSA
I used the Merlin Easy-RSA method. The only hassle was getting the necessary files off the router and onto my computer so that I could install them into the client and server OpenVPN configurations. For some reason, I couldn't access the easy-rsa directory by SMB. I ended up using the command line to copy the files to another directory on the router USB storage that I could access by SMB.
- The next item to add to the Allowed Clients table is the subnet. For the Subnet, enter the LAN IP address range of the client (home) router. This address range is found in the LAN section of the client router. It will end in .0. Mask should be the same value what's entered in the LAN section of the client router. Typically its set to 255.255.255.0. Finally, set Push to "Yes". Then hit the "+" button to the far right of the columns. After completing all these steps, be sure to press the "Apply" button at the bottom of the page.
Unless I have forgotten something, those are the changes that are needed for a bi-direction implementation compared to a typical OpenVPN configuration. I should add some screen shots, but I'm out of time to work on this. If Option 1) or 2) are used for dealing with the Common Name limitation of the built-in client certificate generation tool, then a new client .ovpn file does not need to be generated for the bi-directional setup.
https://www.snbforums.com/threads/u...o-asus-routers-via-openvpn-in-tun-mode.54868/
I already had a working OpenVPN server that was not operating in bi-directional mode, so the challenge was figuring out what was different than a standard OpenVPN server setup. I eventually realized that for some configs, there was very little difference in the setup, so I decided to create a thread to help simplify the bi-direction setup process for people who already have a working OpenVPN server.
But before I get into the differences, I'd like to first discuss selecting which site is the OpenVPN server and which is the client. I need a bi-directional VPN implementation to create a permanent LAN-to-LAN link where LAN-to-LAN data transfers and communication can be initiated from either LAN. This is a different need than simply wanting to access a home network from a remote location, such as while on travel. In particular, I want IP cameras at the remote sites to send their recordings to my home NAS, and I want to be able to manage those IP cameras from my home network. I spend relatively little time at the remote sites, so for these needs, I think its preferable to make the remote site the OpenVPN server and make the home site the client. That way, I can initiate or terminate the VPN tunnel from home. A limitation of using these server/client roles with the OEM firmware is that the client router can only connect to one OpenVPN server at a time. So multiple remote LANs cannot be linked to the home LAN using these client/server roles with the OEM firmware. There are two ways to get around this when multiple remote LANs need to be connected to the home network.
For the OEM firmware, its possible to get around this by switching the server/client roles, i.e., make the home network the server, and make the remote sites the clients. The main challenge with the reversed role is control over the link between the home and remote sites. The OpenVPN client implementation can be set up to automatically reconnect after a power cycle, but if for some reason there is a need to stop and/or restart a connection, it requires having another way to get into the remote network to do this. One means is to temporarily enable access to the remote router via the web GUI from the internet, but this is discouraged. Another means is to have a device at the remote site that has RDC or some other network access server installed on it.
The other option for having multiple remote sites connected to the home network is to use Merlin firmware on the home router. Merlin firmware allows up to six OpenVPN client sessions to run at once. Merlin firmware also includes the current implementation of OpenVPN, there are more options in server and client setup, and it allows for a more efficient cipher to be used (GCM) if Merlin firmware is installed on the home and remote routers.
I eventually settled on installing Merlin firmware on all the routers along with setting up the remote sites to act as OpenVPN servers.
ok, so what's different than a typical ASUS router OpenVPN configuration? I am covering this so that people who already have an OpenVPN server can quickly transition to the bi-directional mode. These changes are specific to the situation where the home router is acting as the OpenVPN client. Here's what needs to be changed:
- The LAN IP address range (in the "LAN" setting) of all the routers being linked needs to be different to prevent routing conflicts. I've been sticking to 192.168.XXX.YYY with XXX being different for each router but do whatever you want as long as you are not producing routing conflicts and are using private IP addresses.
- Change the OpenVPN server subnet address on each router (in OpenVPN server Advanced settings). This is also needed to prevent routing conflicts. If you only use the client router as an OpenVPN client (with the OpenVPN server on that router disabled), and if you only have one remote site, then changing the OpenVPN server Subnet address isn't necessary. The OpenVPN server Subnet address needs to be different at each site. My way of selecting a VPN server subnet address is as follows. If the router LAN IP address for the server (listed in the *LAN* settings for the router) is WWW.XXX.YYY.ZZZ (where WWW.XXX is not 10.8), then I set the server VPN Subnet to 10.8.YYY.0.
- In the OpenVPN server "Advanced" setting, enable "Manage Client-Specific Options". Then enable "Allow Client <-> Client".
- Add an entry to the "Allowed Clients" table for the client that will be connecting. There are three ways to approach setting up this table, and this is where this process can become more complicated. The three options are related to a trade-off between OpenVPN security and ease of bi-directional setup. The first column in the Allowed Clients table is a means to identify a client to set up the appropriate routing. In the situation where standard OpenVPN security measures are used, a client Common Name is entered. This name is generated when the client OpenVPN certificate is created. However, there is no means to specify a unique client Common Name when using the client certificate generation tool built into the OEM OpenVPN implementation. The built-in ASUS tool sets the client Common Name to "client". Being stuck with "client" as the Common Name is fine if the server is only going to have a single connection from a particular site. However, if there is intent to have multiple clients (e.g., LAN-to-LAN as well as say computer-to-LAN), then this option breaks because each client connecting to the OpenVPN server needs a unique Common Name for bi-directional implementation. If all clients have the same Common Name ("client"), then when a second client tries to connect, the first one gets booted, and a battle for the connection ensues. One way to get around this is to move away from using Common Name to identify the client, but doing this requires reducing OpenVPN security. The other way to get around the limitation of the built-in client certification generation tool is to create your own certificates using Easy-RSA. Here is the scoop on each method along with their limitations:
1) Do like the OP of the Guide thread did where he reduced login security by enabling the option, "Username/Password Auth. Only". This does away with client/server certificate authentication which is part of the standard security protocol. It is generally not recommended, although to be honest, I'm not sure how much of a security issue it is. When this option is enabled, the heading of the first column in the Allowed Clients table becomes, "username", and then usernames from the list created on the General page of the OpenVPN server setup are used. With this method, its possible to easily have multiple clients connected to the OpenVPN server, but at reduced security.
2) Do not enable "Username/Password Auth. Only", and use "client" as the Common Name. As already discussed, standard security is maintained, and this setup works fine if there is only ever going to be a single connection to the VPN server. It doesn't work for multiple clients connecting to the server in bi-directional mode.
3) Generate your own certificates and keys using Easy-RSA. This is really not hard, but it felt rather involved the first time I did it. All necessary certificates and supporting items for the client and server have to be generated and inserted into the client and server configurations. Creating these items using Easy-RSA can be done a few different ways. The Merlin firmware install includes the capability to separately run Easy-RSA on the router command line. However it requires some knowledge of command line, and it requires a USB drive to be installed on the server router. The other means is to run the Windows, Mac, Unix, etc. versions of Easy-RSA. There are how-to guides on the internet for any of these Easy-RSA methods. In particular, the how-to for the Merlin-based method is here:
https://github.com/RMerl/asuswrt-merlin/wiki/Generating-OpenVPN-keys-using-Easy-RSA
I used the Merlin Easy-RSA method. The only hassle was getting the necessary files off the router and onto my computer so that I could install them into the client and server OpenVPN configurations. For some reason, I couldn't access the easy-rsa directory by SMB. I ended up using the command line to copy the files to another directory on the router USB storage that I could access by SMB.
- The next item to add to the Allowed Clients table is the subnet. For the Subnet, enter the LAN IP address range of the client (home) router. This address range is found in the LAN section of the client router. It will end in .0. Mask should be the same value what's entered in the LAN section of the client router. Typically its set to 255.255.255.0. Finally, set Push to "Yes". Then hit the "+" button to the far right of the columns. After completing all these steps, be sure to press the "Apply" button at the bottom of the page.
Unless I have forgotten something, those are the changes that are needed for a bi-direction implementation compared to a typical OpenVPN configuration. I should add some screen shots, but I'm out of time to work on this. If Option 1) or 2) are used for dealing with the Common Name limitation of the built-in client certificate generation tool, then a new client .ovpn file does not need to be generated for the bi-directional setup.
Last edited:
