Bi-directional VPN on ASUS routers set-up

[ajsrockstar]

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

Thanks @eibgrad - sorry if it sounded like i was complaining. i didn't mean it to come across that way. I am truly appreciative of the help you are giving.

I'm gathering the dumps you suggested. Just to check - do I need to try to a connection to capture the traffic in these dumps or are they just static definition tables?

 

[eibgrad]

Thanks @eibgrad - sorry if it sounded like i was complaining. i didn't mean it to come across that way. I am truly appreciative of the help you are giving.

I'm gathering the dumps you suggested. Just to check - do I need to try to a connection to capture the traffic in these dumps or are they just static definition tables?

Generating some traffic would at least show rules being hit, so it helps. But for the most part, I just want to confirm *statically* that things are configured wrt the routing and firewall as I expect them to be. That's why things sometimes don't work. Something unexpected has worked its way into the mix, and I'm hoping to spot it. Not likely, but worth checking.

 

[ajsrockstar]

Thanks @eibgrad - attached file contains dumps of firewall and routing tables from the client router.

 

[eibgrad]

Thanks @eibgrad - attached file contains dumps of firewall and routing tables from the client router.

I'd still like to see the OpenVPN server's router as well.

Based on what I see on the OpeVPN client's router, I have the following observations.

1) I was surprised the tunnel network interface was named tun15. I was under the impression that the OEM/stock firmware only supported *one* OpenVPN client. In the case of Merlin, it's up to five, and their names are tun11, tun12, tun13, tun14, and tun15 respectively. Not that it represents a problem per se, but it made to wonder if perhaps this *is* Merlin on the OpenVPN client. But looking at other data structures, it appears NOT to be,

2. I can see both the INPUT and FORWARD chains are NOT preventing inbound access to the OpenVPN client's tunnel (tun15).

3. I can see you've NAT'd the OpenVPN client over the tunnel. But in a properly configured site-to-site tunnel, there's no need for either side to NAT the tunnel since each has all the information it needs in order to route to the others local IP network. You only use NAT when that it is NOT the case. So I'm wondering if you disabled NAT on theOpenVPN client whether even that would stop working, suggesting the problem lies on the OpenVPN server side (i.e., it actually doesn't know how to route back to the devices that initiate a connection from client to server).

 

[ajsrockstar]

I'd still like to see the OpenVPN server's router as well.

Based on what I see on the OpeVPN client's router, I have the following observations.

1) I was surprised the tunnel network interface was named tun15. I was under the impression that the OEM/stock firmware only supported *one* OpenVPN client. In the case of Merlin, it's up to five, and their names are tun11, tun12, tun13, tun14, and tun15 respectively. Not that it represents a problem per se, but it made to wonder if perhaps this *is* Merlin on the OpenVPN client. But looking at other data structures, it appears NOT to be,

2. I can see both the INPUT and FORWARD chains are NOT preventing inbound access to the OpenVPN client's tunnel (tun15).

3. I can see you've NAT'd the OpenVPN client over the tunnel. But in a properly configured site-to-site tunnel, there's no need for either side to NAT the tunnel since each has all the information it needs in order to route to the others local IP network. You only use NAT when that it is NOT the case. So I'm wondering if you disabled NAT on theOpenVPN client whether even that would stop working, suggesting the problem lies on the OpenVPN server side (i.e., it actually doesn't know how to route back to the devices that initiate a connection from client to server).

Server firewall and routing dumps attached. To the points you raised:

1. The router was bought from Amazon and the firmware version is 3.0.0.4.386_47029. So unless Merlin was pre-installed without me knowing prior to shipment then afaik I am running the stock ASUS firmware. tun15 was just what it generated when I set up the client. I had no choice in that.

2. That's good to know.

3. I did not explicitly NAT the OpenVPN client over the tunnel. Must be either a factory-setting or something done automatically when I set up the client. I can turn it off if you can let me know where to look in the admin pages.

 

[eibgrad]

I wasn't actually suggesting you're using Merlin. As I said, it initially appeared to be the case given the use of the tun15 network interface name. You would normally expect to see something like tun0 or tun1 for oem/stock firmware (at least I would). tun15 seems so specific, as if it was Merlin. But the rest of what I saw in the dumps suggests it's NOT Merlin.

As far as NAT, I have to continually remind myself your routers are using OEM/stock firmware (I deal w/ so many threads at the same time, then have to revisit them in and out of order, and most are Merlin, that I sometimes just lose track). It's likely the OEM/stock firmware doesn't even provide the option to enable/disable NAT on the tunnel. They just keep it simple. It will still work w/ NAT enabled, but as I said, normally in a site-to-site config, you would NOT use NAT.

As far as the dumps, I don't see anything wrong there as well. The routing and firewall rules look correct.

Then I got to thinking about the suggestion made by @elorimer regarding username/passwords.

Since (apparently) you generated all your own certs and keys, and provided unique ones for your various OpenVPN clients, there's no need to use the username-as-common-name directive. You should just use the actual CN (Common-Name) you specified on the client cert(s) when configuring Manage Client-Specific Options.

What I'm concerned about is whether you perhaps used the login name of the client in Manage Client-Specific Options, esp. if you didn't specify the username-as-common-name directive. That would have created a client-specific file under the CCD directory that doesn't match the CN on the client's cert. And if that happened, then the iroute created by the router within that file would NOT work.

IOW, if the client's cert is named 'client' (no quotes), and you used that for Manage Client-Specific Options, then there should be a file called /tmp/etc/openvpn/server1/ccd/client that contains an iroute of 192.168.50.0 255.255.255.0.

 

[ajsrockstar]

Thanks again @eibgard. TBH I am amazed at your ability to switch between multiple threads at the same time and still maintain continuity of the context. And I am also extremely grateful for that.

Just to confirm - based on your previous advice I did not opt for the username-as-common-name approach and stayed with the individual certificates. For the client router I generated a certificate and key with a common name of cn_itnc by following the instructions in the post by @jsshapiro.

Now here are the user names configured on the server

And here is the list of Allowed Clients:

and with the client ovpn connection activated on the server I see a file called /tmp/etc/openvpn/server1/ccd/cn_itnc that contains an iroute of 192.168.50.0 255.255.255.0

On the client router here is what I configured for the OVPN client:

View attachment 39876

In the client OPVN config dialog I uploaded a .ovpn file called itnc.ovpn created by editing the .ovpn file exported from the server to replace the certificate and key for 'client' with the certificate and key I generated for cn_itnc (as described in the posting by @jsshapiro).

You'll see in my client definition I included username and password. Seeing that these are optional I wondered whether by including username and password this was in some way overriding or conflicting with what is in the cn_itnc.ovpn configuration file. I created another profile without the optional username and password and uploaded cn_itnc.ovpn but when I try to activate that new profile it does not activate and the timer just ticks around until I click to deactivate.

I then updated the new profile to manually edit the certificates and keys to clear the client security certificates and keys and paste in those I had generated for cn_itnc just in case the keys embedded in the cn_itnc.ovpn configuration file had somehow got corrupted. But again this profile would not activate without the optional username and password.

So if I'm understanding you correctly it looks like everything is set up as expected but something is still blocking. I'm wondering if switching to Merlin might be a next step, the problem being I think I could only do that on the client router because I would need to VPN into the server router and I guess when I loaded Merlin all my stock ASUS-WRT config would disappear and I'd be dead in the water at that point.

Any idea what I can try next? Is there a way to capture the traffic between the routers to see where the route gets broken?

Thanks again for sharing your expertise and your patience and understanding for a novice.

Andy

 

[ajsrockstar]

Thanks again @eibgard. TBH I am amazed at your ability to switch between multiple threads at the same time and still maintain continuity of the context. And I am also extremely grateful for that.

Just to confirm - based on your previous advice I did not opt for the username-as-common-name approach and stayed with the individual certificates. For the client router I generated a certificate and key with a common name of cn_itnc by following the instructions in the post by @jsshapiro.

Now here are the user names configured on the server

View attachment 39877

And here is the list of Allowed Clients:

View attachment 39874

and with the client ovpn connection activated on the server I see a file called /tmp/etc/openvpn/server1/ccd/cn_itnc that contains an iroute of 192.168.50.0 255.255.255.0

On the client router here is what I configured for the OVPN client:

View attachment 39876

In the client OPVN config dialog I uploaded a .ovpn file called itnc.ovpn created by editing the .ovpn file exported from the server to replace the certificate and key for 'client' with the certificate and key I generated for cn_itnc (as described in the posting by @jsshapiro).

You'll see in my client definition I included username and password. Seeing that these are optional I wondered whether by including username and password this was in some way overriding or conflicting with what is in the cn_itnc.ovpn configuration file. I created another profile without the optional username and password and uploaded cn_itnc.ovpn but when I try to activate that new profile it does not activate and the timer just ticks around until I click to deactivate.

I then updated the new profile to manually edit the certificates and keys to clear the client security certificates and keys and paste in those I had generated for cn_itnc just in case the keys embedded in the cn_itnc.ovpn configuration file had somehow got corrupted. But again this profile would not activate without the optional username and password.

So if I'm understanding you correctly it looks like everything is set up as expected but something is still blocking. I'm wondering if switching to Merlin might be a next step, the problem being I think I could only do that on the client router because I would need to VPN into the server router and I guess when I loaded Merlin all my stock ASUS-WRT config would disappear and I'd be dead in the water at that point.

Any idea what I can try next? Is there a way to capture the traffic between the routers to see where the route gets broken?

Thanks again for sharing your expertise and your patience and understanding for a novice.

Andy

Damn! screenshot of client got dropped somehow. trying again:

 

[eibgrad]

As I stated previously, there is no requirement by OpenVPN that you use username/passwords when using individual client certs and keys. In most cases, ppl don't. But being this is oem/stock firmware, perhaps it's a requirement imposed by the GUI. It doesn't really matter as long as you're getting connected and the server is accessing the correct file for that user based on their CN (Common Name). I was just concerned that maybe there was an issue where perhaps the username was being used instead of the CN.

Another option is to NOT create a single site-to-site tunnel, but create two unidirectional tunnels. IOW, each side connects its own OpenVPN client to the other's OpenVPN server. I've done this myself in the past when I didn't always want bidirectional access. It also removes any dependencies on the remote side being connected for the local side to gain access in the other direction. And we bypass all this Manage Client-Specific Options stuff.

Of course, this doesn't explain *why* the current config isn't working. But NOT having access to the OEM/stock firmware is a major disadvantage. It still seems to me this is a firewall issue on those remote clients, because once you have the routing correct, and there's nothing blocking access on the routers' firewalls, that's really all that's left.

Maybe the setup is entirely correct and there's simply a bug we don't know about preventing the access.

P.S. I had one other idea. Let's try NAT'ing the server side of the tunnel (similar to how the client side is NAT'd) to see if that makes a difference.

iptables -t nat -I POSTROUTING -o tun21 -j MASQUERADE

 

[ajsrockstar]

As I stated previously, there is no requirement by OpenVPN that you use username/passwords when using individual client certs and keys. In most cases, ppl don't. But being this is oem/stock firmware, perhaps it's a requirement imposed by the GUI. It doesn't really matter as long as you're getting connected and the server is accessing the correct file for that user based on their CN (Common Name). I was just concerned that maybe there was an issue where perhaps the username was being used instead of the CN.

Another option is to NOT create a single site-to-site tunnel, but create two unidirectional tunnels. IOW, each side connects its own OpenVPN client to the other's OpenVPN server. I've done this myself in the past when I didn't always want bidirectional access. It also removes any dependencies on the remote side being connected for the local side to gain access in the other direction. And we bypass all this Manage Client-Specific Options stuff.

Of course, this doesn't explain *why* the current config isn't working. But NOT having access to the OEM/stock firmware is a major disadvantage. It still seems to me this is a firewall issue on those remote clients, because once you have the routing correct, and there's nothing blocking access on the routers' firewalls, that's really all that's left.

Maybe the setup is entirely correct and there's simply a bug we don't know about preventing the access.

P.S. I had one other idea. Let's try NAT'ing the server side of the tunnel (similar to how the client side is NAT'd) to see if that makes a difference.

iptables -t nat -I POSTROUTING -o tun21 -j MASQUERADE

Thanks for your further thoughts. Funnily enough my original idea was to have two separate tunnels but this seemed to be thwarted by the fact that my current client router is behind a double-NAT and as I understand it this would require my ISP to either give me a public IP address or open ports on their routers. They won't do the latter and to get a public IP address they want me to give them my life savings, my home, my car, my kids..... (The UK ISP who provides service to my server router billed me a one-time charge of GBP 5 a static public IP for as long as I want it). So the bi-directional VPN with the client behind the double NAT seemed like the only option.

I will certainly try NAT'ing on the server side but now I run into a practical problem which is that I may not be able to test the change in the near future because there is once again nobody in the server router location who can try connecting from a device on the server subnet to a device on the client subnet. So it could be some time before I am able to post an update on whether that change did the trick.

In the meantime I am thinking more about a staged migration to Merlin as a step to getting this to work. My idea is to first migrate the client router (which is where I am physically located) and make sure I can still at least run the uni-directional tunnel to the stock firmware server router. With luck the bi-directional tunnel might magically open up. But if it doesn't, in a few weeks time I will be back in the same location as the server router and can migrate it to Merlin, recreate the OpenVPN server at which point I assume the client router will just re-open the tunnel after it gets dropped during the Merlin install on the server, and either I will have a bi-directional connection or I won't. If it still leaves me with a unidirectional client I wouldn't of course be able to use the tunnel to try any further changes on the client side but I could at least make changes on the server side. And if after all that I can't get it to work then I would be no worse off than where I am right now.

I'd welcome any hints, tips and words of warning about my staged approach to migrate to Merlin. I haven't ever changed firmware on a router before so I'm nervous about bricking them.

Andy

 

[ajsrockstar]

Thanks for your further thoughts. Funnily enough my original idea was to have two separate tunnels but this seemed to be thwarted by the fact that my current client router is behind a double-NAT and as I understand it this would require my ISP to either give me a public IP address or open ports on their routers. They won't do the latter and to get a public IP address they want me to give them my life savings, my home, my car, my kids..... (The UK ISP who provides service to my server router billed me a one-time charge of GBP 5 a static public IP for as long as I want it). So the bi-directional VPN with the client behind the double NAT seemed like the only option.

I will certainly try NAT'ing on the server side but now I run into a practical problem which is that I may not be able to test the change in the near future because there is once again nobody in the server router location who can try connecting from a device on the server subnet to a device on the client subnet. So it could be some time before I am able to post an update on whether that change did the trick.

In the meantime I am thinking more about a staged migration to Merlin as a step to getting this to work. My idea is to first migrate the client router (which is where I am physically located) and make sure I can still at least run the uni-directional tunnel to the stock firmware server router. With luck the bi-directional tunnel might magically open up. But if it doesn't, in a few weeks time I will be back in the same location as the server router and can migrate it to Merlin, recreate the OpenVPN server at which point I assume the client router will just re-open the tunnel after it gets dropped during the Merlin install on the server, and either I will have a bi-directional connection or I won't. If it still leaves me with a unidirectional client I wouldn't of course be able to use the tunnel to try any further changes on the client side but I could at least make changes on the server side. And if after all that I can't get it to work then I would be no worse off than where I am right now.

I'd welcome any hints, tips and words of warning about my staged approach to migrate to Merlin. I haven't ever changed firmware on a router before so I'm nervous about bricking them.

Andy

I just spotted one flaw in this plan. Merlin is not supported on RT-AX82U (my server router) but at least I can still do the first stage and migrate the RT-AX3000 client router (which is listed as supporting Merlin). And if that solves the problem stage 2 becomes unnecessary.

 

[ajsrockstar]

Unfortunately I still haven't solved the technical problem but I have found another way to meet the essential 'user requirement' which is to have remote access over the internet to devices on a LAN which is behind a double NAT and has no static public IP address.

I have achieved this by signing up for OpenVPN Cloud and connecting the double-NAT's router as an OpenVPN client to my OpenVPN Cloud network. When I connect a client PC or smart phone to the same OpenVPN Cloud network I can now access all the devices behind the client router. It's not as elegant as a bi-directional tunnel between my two routers, and I had wanted to avoid a third party VPN service, but at the end of the say it meets my key requirement.

I may continue to try to solve the bi-directional tunnel problem because I'd still prefer that approach. But one big problem I am facing is that I have to use the uni-directional tunnel from the client router to the server router to run any diagnostics and make any configuration changes. As I have learned to my cost once already, one mis-configuration may bring down the tunnel and of course then there is no way to back out the changes (other than by having access to the router admin screens from the WAN enabled which is a risk I prefer to avoid if possible).

Anyhow, thanks again to @eibgrad and @elorimer for their help with this. If I do ever get the bi-directional tunnel working I will update this thread.

 

[eibgrad]

I still think it's highly likely the problem is a bug w/ the oem/stock firmware. But when that happens, you're basically stuck. There really is nowhere to turn other than third-party firmware. And it's why so many of us avoid any routers that don't support it. We don't want to find ourselves without options.

Frankly, using the cloud as a solution isn't a bad idea. In fact, if I was forced to do the same, I'd probably have *both* sites configured as OpenVPN clients to the same cloud server and use it as a gateway (i.e., client to client)! That way, any connected OpenVPN client has access to either network at the same time. And if you had a need for even a third or fourth site, this would actually scale much better.

 

[ajsrockstar]

I still think it's highly likely the problem is a bug w/ the oem/stock firmware. But when that happens, you're basically stuck. There really is nowhere to turn other than third-party firmware. And it's why so many of us avoid any routers that don't support it. We don't want to find ourselves without options.

Frankly, using the cloud as a solution isn't a bad idea. In fact, if I was forced to do the same, I'd probably have *both* sites configured as OpenVPN clients to the same cloud server and use it as a gateway (i.e., client to client)! That way, any connected OpenVPN client has access to either network at the same time. And if you had a need for even a third or fourth site, this would actually scale much better.

Funnily enough I have configured both sites to the same cloud server to use it as client to client gateway and that does indeed enable me to access both networks from an OpenVPN client on my PC or phone. The documentation also seems to suggest it should work as a bi-directional VPN between sites like I was hoping to achieve, but - surprise, surprise - that isn't working yet either but I don't know I'll spend too much time trying to get that working because as I said, it would be very convenient but not essential.

Thanks again for your help. Very much appreciated.

 

[AlanOng]

I am a GUI person with minimum knowhow but after reading your threads and other, I manage to linkup 2 ASUS routers (RT-AC88U & RT-AC68U) via the VPN tunnels.

Initially, I can only reach devices on Server VPN router from the LAN of Client VPN router. After enabling the Manage Client-Specifiic Options and selecting Allowed Clients <>Client and adding subnet of local LAN of Client VPN with CN 'client', it didn't work but I can see from VPN status that the route is there.

Then I recalled from a comment about the Firewall at the Client VPN router which I set to 'Allow' for Inbound Firewall and it finally works perfectly.

As I have not much confident to implement multiple VPN Clients (phone/tablet) to Servers, guess I will create another VPN Server just for remote client VPN access.

I am on Merlin 386.7 2 for both ASUS routers.

Thank you guys