Bi-directional VPN on ASUS routers set-up

[ajsrockstar]

I am trying to set up a bi-directional OpenVPN tunnel between two ASUS routers. RT-AX82U hosts the built-in ASUS-WRT OpenVPN server and RT-AX3000 hosts the built-in ASUS-WRT OpenVPN client. I have foillowed the instructions given in these two excellent posts to do this:

Tutorial - Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Part 1 This guide will help you connect two ASUS routers in Site To Site (also know as Point To Point) mode. I'm listing literally every step I take so you should be able to just follow along...

www.snbforums.com

Tutorial - [Solved] Setup for Bi-directional VPN with WRT-based Routers (e.g. ASUS)

Part 1: Context and Goal In early 2019, Ed B. posted his Ultimate Guide to setting up a bi-directional VPN using ASUS routers. He did a fantastically thorough job describing what he did. Most of it is right, and you should use his post as a place to get started. Unfortunately, he got a critical...

www.snbforums.com

As per those two posts, I have generated individual certificates and keys for the client router and taken great care to make sure there is no overlap and conflict of IP addresses between the two subnets:

RT-AX82U (running OpenVPN server) subnet/mask 192.168.0.1 /255.255.255.0
OpenVPN server on RT-AX82U subnet/mask 10.8.0.0 /255.255.255.0
RTAX3000 (running OpenVPN client) subnet/mask 192.168.50.1 /255.255.255.0


The client connects successfully to the server and from a PC on the client 192.168.50.1 subnet I can connect to and log into devices on the server 192.168.0.1 subnet. But I am not able to make the reverse connection i.e. use a PC connected to the server subnet to connect to and log into devices on the client subnet. I have also tried connecting my mobile phone running OpenVPN client over a 4G cellular connection but the result is the same - I can connect to devices on the server subnet but not to devices on the client subnet. (In the OpenVPN server config I have configured the setting Allow Client <-> Client:Yes).

When I first configured and activated the OpenVPN client on the RT-AX3000 I got an error message "IP/Routing conflict: Please change your router LAN subnet, please refer to this FAQ for detail". I don't understand why this conflict occurs given the above subnet/mask configurations. And despite the error message the uni-directional client -> server connection worked fine. Back on the server I changed the definition of the Allowed Client for the client router to switch the 'Push' parameter from Yes to No. This at least resolved the IP/Routing conflict message but I can still only get the uni-directional client -> server connection working.

I see other posts suggesting various solutions involving entries in the router routing tables and/or route and iroute directives in the custom configration box in the OpenVPN server advanced settings but I don't have the advanced networking knowledge and skills necessary to try those out without risking completely screwing up the OpenVPN server router (which incidentally is in an unoccupied house 6000 miles away from me!).

I know that other people have followed the instructions in the above-referenced posts and report they succeeded in getting bi-directional VPN working so I'm asking if anybody has any suggestons as to what else I might try?

 

[elorimer]

I assume in addition to certificates you are using a name/password login as well? This is what works for me on Merlin:

1. On the server side, set up a client with a login name for the client router.
2. On the server side, click "manage client specific options" on.
3. On the server side, under custom configuration, enter "username-as-common-name"
4. Under add in the boxes, the login name for the client router under "Common Name", "192.168.50.0" under "Subnet", "255.255.255.0" under "Mask", and "No" under "Push".

It is more complicated if you are combining three networks.

 

[ajsrockstar]

I assume in addition to certificates you are using a name/password login as well? This is what works for me on Merlin:

1. On the server side, set up a client with a login name for the client router.
2. On the server side, click "manage client specific options" on.
3. On the server side, under custom configuration, enter "username-as-common-name"
4. Under add in the boxes, the login name for the client router under "Common Name", "192.168.50.0" under "Subnet", "255.255.255.0" under "Mask", and "No" under "Push".

It is more complicated if you are combining three networks.

Hi @elorimer - thanks for the suggestions. I confirm I already have 1, 2 and 4 set up as you describe.

As per your item 3 I haven't seen "username-as-common-name" mentioned in other posts. What does it do?

 

[ajsrockstar]

I just took a look at the routing table entries on both routers. On the client RT-AX3000 I see these entries relating to the OpenVPN routes:

Destination Default	Gateway	Genmask	Flags	Metric	Ref	Use Type	Iface
10.8.0.0	10.8.0.5	255.255.255.0	UG	0	0	0	tun15
10.8.0.5	*	255.255.255.255	UH	0	0	0	tun15
192.168.0.0	10.8.0.5	255.255.255.0	UG	0	0	0	tun15

On the server RT-AX82U I only see these two entries:

10.8.0.0	10.8.0.2	255.255.255.0	UG	0	0	0	tun21
10.8.0.2	*	255.255.255.255	UH	0	0	0	tun21

I kind of expected there would be a routing table entry on the server side similar to the last of the above entries on the client side i.e.

192.168.50.0

10.8.0.2

255.255.255.0

UG

0

0

0

tun21

but there isn't. Should there be? And if so how do I add an entry - the WRT configuration page for adding static routes doesn't allow me to enter values for Flags, Ref, or Use Type and values for Iface are limited to LAN, WAN and MAN. Is this something I would need to do with appropriate OpenVPN directives added to the custom configuration box in the Advanced Settings for the OpenVPN server?

 

[eibgrad]

Normally adding the details for the OpenVPN client to the Manage Client-Specific Options section just works. And you would see a route for it in the server's routing table. The fact you do NOT makes me wonder if perhaps you didn't hit the Add button before saving the changes! It's easy to think that simply filling in those fields is sufficient. But you have to explicitly add the entry, then save.

 

[ajsrockstar]

Normally adding the details for the OpenVPN client to the Manage Client-Specific Options section just works. And you would see a route for it in the server's routing table. The fact you do NOT makes me wonder if perhaps you didn't hit the Add button before saving the changes! It's easy to think that simply filling in those fields is sufficient. But you have to explicitly add the entry, then save.

Indeed - I have learnt that lesson from many times forgetting to do it. But I can confirm the client was correctly Added and Applied in the Manage Client-Specific Options section.

I have since found out how to temporarily add the "missing" routing record to the routers routing table but it hasn't solved the problem. However, I just spotted something. When de-activating and re-activating the VPN connection at the client end this showed up in the server router's general log:

cn_itnc/74.xxx.xx.xx:43358 Options error: in --iroute 192.168.50.1 255.255.255.0 : Bad network/subnet specification

cn_itnc is the common name i gave to the OpenVPN client running on the client router

I've masked the IP address 74.xxx.xx.xx:43358 because I suspect that this is the public IP address and port of the client router, although on the client router the WAN IP address is 100.xx.x.xx. This makes me suspect that that router is behind a double NAT. Maybe that accounts for the bad iroute specification because 192.168.50.1 is a private address hidden behind another private address? Just guessing, but if that's the case I don't see how I can ever get traffic initiated at the server end to flow to the client because two of the three addresses along the route can change, my ISP wants to gouge me for a static public IP address, and DDNS doesn't get around a double NAT.

I'd be truly delighted to be proved wrong about that diagnosis but I'm close to concluding that a bi-directional VPN is not achievable with my current ISP connection.

 

[eibgrad]

Sounds like you specified 192.168.50.1 255.255.255.0 for the IP network in Manage Client-Specific Options, when it needs to be 192.168.50.0 255.255.255.0.

 

[ajsrockstar]

Sounds like you specified 192.168.50.1 255.255.255.0 for the IP network in Manage Client-Specific Options, when it needs to be 192.168.50.0 255.255.255.0.

You are an absolute wizard! That was exactly the problem. I just corrected the Client-Specific Options for that client and have been able to ping a device on the client network.

So I am truly happy to be proved wrong about the double NAT thing. Thanks again for your advice and guidance. It is truly apprecioated.

 

[elorimer]

As per your item 3 I haven't seen "username-as-common-name" mentioned in other posts. What does it do?

As I learned from a different post by @eibgrad, who is the master at this, the certificates generated by the router all have the same CN of "client". So OpenVPN would always apply the same setup for anyone connecting. You'd be thoroughly messed up if you had two devices connected to your Servers. If you include that setting, however, OpenVPN applies different settings based on different login usernames, so if you have a unique username for the second site, you get unambiguous routing to the second site.

 

[ajsrockstar]

As I learned from a different post by @eibgrad, who is the master at this, the certificates generated by the router all have the same CN of "client". So OpenVPN would always apply the same setup for anyone connecting. You'd be thoroughly messed up if you had two devices connected to your Servers. If you include that setting, however, OpenVPN applies different settings based on different login usernames, so if you have a unique username for the second site, you get unambiguous routing to the second site.

I knew about the single certificate problem from the thread posted by @jsshapiro so I followed his instructions for generating unique certificates for each site. Sounds like "username-as-common-name" would have avoided the need for me to dive into the murky waters of Linux of which I have limited knowledge. Oh well - I'll put that down to experience and if I have to do this again I'll try the approach with "username-as-common-name".

Thanks again for your very helpful posts.

 

[eibgrad]

I knew about the single certificate problem from the thread posted by @jsshapiro so I followed his instructions for generating unique certificates for each site. Sounds like "username-as-common-name" would have avoided the need for me to dive into the murky waters of Linux of which I have limited knowledge. Oh well - I'll put that down to experience and if I have to do this again I'll try the approach with "username-as-common-name".

Thanks again for your very helpful posts.

Generating individual and unique certs and keys for each client is the *correct* procedure when dealing w/ an OpenVPN server intended to support site-to-site. But it's a major inconvenience for most users since it means having to roll-your-own w/ EasyRSA. It's much easier to simply depend on the one set of client cert/keys auto-generated by the router and disambiguate users based on their username. And that's when the username-as-common-name directive becomes necessary. But again, imo, you should NOT be relying on that (admittedly convenient) technique for site-to-site configurations. In fact, once users have their own certs and keys, the use of username/password becomes superfluous. Continuing to use them would be like configuring public/private keypairs for SSH and still requiring a password. You just wouldn't do it.

 

[ajsrockstar]

Generating individual and unique certs and keys for each client is the *correct* procedure when dealing w/ an OpenVPN server intended to support site-to-site. But it's a major inconvenience for most users since it means having to roll-your-own w/ EasyRSA. It's much easier to simply depend on the one set of client cert/keys auto-generated by the router and disambiguate users based on their username. And that's when the username-as-common-name directive becomes necessary. But again, imo, you should NOT be relying on that (admittedly convenient) technique for site-to-site configurations. In fact, once users have their own certs and keys, the use of username/password becomes superfluous. Continuing to use them would be like configuring public/private keypairs for SSH and still requiring a password. You just wouldn't do it.

Thanks for your thoughts @eibgrad. I'll certainly be weighing up the pros and cons of both approaches if I have to do this again. In the meantime...

It seems I was premature in saying all is working. Because I am physically located at the client site I cannot use a device which is directly connected to the server subnet to test a connection from a device on the server subnet to a device on the client subnet. The best I can do is connect my PC to the server router via the vpn tunnel, sign into the router administration ui and issue a ping from there back to a device on the c;lient subnet. And this worked - I got a response to pings.

But today I managed to find a friend who could get into the property where the server router is and got him to connect his PC and key in the IP address of the client router into a browser to see if he could bring up the router admin log-in screen. I also gave him the aaddress of the NVR which sits on the client subnet and asked him to try to get access to the log in scrreen for that too The result in both cases was an error message "Site cannot be reached".

Seems like pinging from the server router get's an "I'm here response" but I need to do something else to get the door(s) to open. Any ideas what else I can try?

 

[eibgrad]

Thanks for your thoughts @eibgrad. I'll certainly be weighing up the pros and cons of both approaches if I have to do this again. In the meantime...

It seems I was premature in saying all is working. Because I am physically located at the client site I cannot use a device which is directly connected to the server subnet to test a connection from a device on the server subnet to a device on the client subnet. The best I can do is connect my PC to the server router via the vpn tunnel, sign into the router administration ui and issue a ping from there back to a device on the c;lient subnet. And this worked - I got a response to pings.

But today I managed to find a friend who could get into the property where the server router is and got him to connect his PC and key in the IP address of the client router into a browser to see if he could bring up the router admin log-in screen. I also gave him the aaddress of the NVR which sits on the client subnet and asked him to try to get access to the log in scrreen for that too The result in both cases was an error message "Site cannot be reached".

Seems like pinging from the server router get's an "I'm here response" but I need to do something else to get the door(s) to open. Any ideas what else I can try?

If you can ping to any given device on the client side from the server side, then you know w/ absolute certainty the routing is correct. If other protocols fail, then it's highly likely to be personal firewalls that are preventing access. For example, by default, Windows will NOT allow access by any *private* network other than the one on which it is running. You have to reconfigure its firewall to allow the access. Some other devices have followed MS's lead in this same regard.

Another possibility is that some target devices might not have a default gateway assigned, esp. if they are only intended to be access locally. Of course, a ping would fail too. And if that's the case, they have no way to reply to the "foreign" network of the client.

 

[ajsrockstar]

If you can ping to any given device on the client side from the server side, then you know w/ absolute certainty the routing is correct. If other protocols fail, then it's highly likely to be personal firewalls that are preventing access. For example, by default, Windows will NOT allow access by any *private* network other than the one on which it is running. You have to reconfigure its firewall to allow the access. Some other devices have followed MS's lead in this same regard.

Another possibility is that some target devices might not have a default gateway assigned, esp. if they are only intended to be access locally. Of course, a ping would fail too. And if that's the case, they have no way to reply to the "foreign" network of the client.

Thanks for confirming that a ping response validates the routing is correct, and for your suggestions to look into gateway and firewall configurations.

One of the devices I asked my friend to access is the client ASUS router, the other device is an NVR for the security system. The client router has a firewall enabled with no special firewall rules and it does have a default gateway configured. The NVR has no firewall (at least not one which is documented and user configurable) and it too has a default gateway configured. The server router is also an ASUS router running the same version of ASUS-WRT as the client and the firewall is enabled with no special firewall rules.

So I can understand that a hidden/undocumented firewall on the NVR might block access from a PC on a different subnet. But with the two routers running the same firmware and with the same firewall configuration on both I don't understand why I am able to access the server-side router admin pages via a vpn tunnel from a PC on the client subnet, but can't access the client-side router admin pages via the same vpn tunnel from a PC on the server subnet. If there is some kind of firewall blocking going on based on protocol why is access to the router admin screens (HTTP or HTTPS) work in one direction but not the other? I figure that if I can work that out the same fix is likely to enable access to the NVR (and other devices) behind the router,

Given that the ping shows the routing is correct is there any way I can capture a log of what happens when a PC tries to connect to the client router admin pages via the VPN? Maybe that would give some clues as to why the NVR pages are also not reachable other than by ping?

Thanks for your thoughts and help. Much appreciated by this networking novice.

 

[eibgrad]

To be honest, I didn't bother reading the links you provided in your initial posting. But it's likely they were written before the Inbound Firewall option was added (at least if the client is using Merlin, can't speak for the OEM/stock firmware). This prevents bi-directional tunnels (aka site-to-site) by default. You need to be sure it's set to Allow (the default is Block) in order for devices on the server side to initiate connections to devices on the client side.

But again, if you have the ability to ping from the server side to the client side, that would suggest you've already done so. But we might as well make sure.

 

[ajsrockstar]

To be honest, I didn't bother reading the links you provided in your initial posting. But it's likely they were written before the Inbound Firewall option was added. This prevents bi-directional tunnels (aka site-to-site) by default. You need to be sure it's set to Allow (the default is Block) in order for devices on the server side to initiate connections to devices on the client side.

But again, if you have the ability to ping from the server side to the client side, that would suggest you've already done so. But we might as well make sure.

That makes sense but I can't find the Inbound Firewall option in the router administration pages. Is that perhaps a Merlin option? I'm running ASUS stock firmware.

 

[eibgrad]

That makes sense but I can't find the Inbound Firewall option in the router administration pages. Is that perhaps a Merlin option? I'm running ASUS stock firmware.

Yeah, it is a Merlin option. I just updated my response to include that information before you posted.

 

[eibgrad]

If you have the ability to dump the firewall on each router using ssh, maybe we can see if there's something preventing the access.

iptables -vnL
iptables -t nat -vnL

 

[ajsrockstar]

That makes sense but I can't find the Inbound Firewall option in the router administration pages. Is that perhaps a Merlin option? I'm running ASUS stock firmware.

If you have the ability to dump the firewall on each router using ssh, maybe we can see if there's something preventing the access.

iptables -vnL
iptables -t nat -vnL

OK - I'll try to grab that. In the meantime I tried disabling the firewall on the client router and had somebody try accessing devices via the tunnel again and still no change. That seems to suggest it isn't the firewall blocking.

 

[eibgrad]

OK - I'll try to grab that. In the meantime I tried disabling the firewall on the client router and had somebody try accessing devices via the tunnel again and still no change. That seems to suggest it isn't the firewall blocking.

I understand. But being oem/stock firmware, I have little else to work with. It's NOT like I can configure my system to match yours and use it for diagnostic purposes. All I have your descriptions. And normally, if you follow the instructions in those links, I'd expect it to just work. Since it doesn't, we just have to poke around a bit and see if we happen upon something unexpected.

In fact, you might as well dump the routing tables on each router as well. Maybe something is up there as well.

ip rule
ip route