Asuswrt Merlin: My working OpenVPN configuration for Bi-Directional VPN (router to router)

[nadieaqui]

Asuswrt Merlin: My working OpenVPN configuration for Bi-Directional VPN (router to router, between routers, site to site)

Acknowledgement: eibgard for helping me solve dns issues (Asuswrt Merlin, resolve client lan names on server-side? | SmallNetBuilder Forums (snbforums.com))

Update 2022-03-08: added pic of Server DDNS Host Name setting
Update 2022-02-20: Added configuration for Client router with VPN Director (post #4)

Below is my working OpenVPN configuration for Bi-Directional VPN (router to router, between routers):
Attach are pics of configurations.

Routers: Asus RT-AC68U (Server), and RT-AC68U (Client)
Firmware: Asuswrt Merlin 386.4

Server LAN: 192.168.11.x
Server Domain Name: server.lan
Client LAN: 192.168.22.x
Client Domain Name: client.lan

0. Set Server "WAN - DDNS" Host Name, see pic
1. Config DNS on Server (dnsmasq.conf.add): pass dns request to vpn, and register Client dns for Client Domain Name, see pic.
2. Config Server OpenVPN: The important configs (see pic) are

a. Manage Client-Specific Options​

b. Allow Client<->Client​

c. Allow only specified clients​

d. Allowed Clients​

i. “Common Name(CN)” = client​

ii. “client” is from “VPN – Status” page when Client connects. You can confirm this when the Client connects to the Server​

3. “Export OpenVPN configuration file” (.ovpn) on Server and “Import .ovpn file” on to Client
4. If the Client is using VPN Director, goto Post 4 below. If Client is not using VPN Director, then goto the “VPN Client” page, and make sure “Inbound Firewall” = allow, see pic in this post.

Hope this helps.

 

[eibgrad]

Glad everything is working for you.

A few minor points, since I like to see things perfected (it's my OCD kickin' in).

1. There is no need to NAT the tunnel w/ a properly configured site-to-site config. Each side has the necessary static routing to make that unnecessary. By NAT'ing, you're hiding the client's source IP from the server's network, and that makes it difficult for targets on the server side to properly log who is accessing them, filter out specific clients, etc.

2. In Manage Client-Specific Options, you do NOT need to Push the route. All that entry is doing is informing the server about which IP network(s) lies behind the OpenVPN client w/ the named cert ('client'). You normally only need to Push when you have multiple, concurrent OpenVPN clients connecting to the same server, and want the server to act as a gateway, so they can all communicate w/ each other. In that case, you enable the Client to Client option, and Push the networks. The OpenVPN server will push those networks to all the OpenVPN clients *except* the one that actually is configured w/ it.

3) I generally recommend avoiding the well-known ports (22, 80, 443, 1194, etc.). That makes you an easy target for hackers. Most are looking for this kind of low-hanging fruit. Few will bother to scan ALL your ports in hopes of getting lucky, esp. when there are plenty of others making the same mistake.

These are very minor quibbles, but at least worth mentioning.

 

[nadieaqui]

Glad everything is working for you.

A few minor points, since I like to see things perfected (it's my OCD kickin' in).

1. There is no need to NAT the tunnel w/ a properly configured site-to-site config. Each side has the necessary static routing to make that unnecessary. By NAT'ing, you're hiding the client's source IP from the server's network, and that makes it difficult for targets on the server side to properly log who is accessing them, filter out specific clients, etc.

2. In Manage Client-Specific Options, you do NOT need to Push the route. All that entry is doing is inform the server about which IP network(s) lies behind the OpenVPN client w/ the named cert ('client'). You normally only need to Push when you have multiple, concurrent OpenVPN clients connecting to the same server, and want the server to act as a gateway, so they can all communicate w/ each other. In that case, you enable the Client to Client option, and Push the networks. The OpenVPN server will push those networks to all the OpenVPN clients *except* the one that actually is configured w/ it.

3) I generally recommend avoiding the well-known ports (22, 80, 443, 1194, etc.). That makes you an easy target for hackers. Most are looking for this kind of low-hanging fruit. Few will bother to scan ALL your ports in hopes of getting lucky, esp. when there are plenty of others making the same mistake.

These are very minor quibbles, but at least worth mentioning.

Thank You. Appreciate all the help/suggestions I can get.

 

[nadieaqui]

For Asuswrt Merlin Client Routers using VPN Director.
Here is my configuration to make things work on the Client Router:
0) Add rule to VPN Director to route client to server ("Local IP"=empty and "Remote IP"=192.168.11.0/24"), see attached image.
1) Create NAT on Tunnel = YES
2) Inbound Firewall = Allow
3) Redirect Internet traffic through tunnel = VPN Director (policy rules)
See attached images

 

[steef84]

Nice write up @nadieaqui.

Just followed this post and got bi directional VPN working.

Thanks for this post.

 

[Jeff-]

Just using VPN on router to provide VPN on Roku. Besides the easy to find RTFM I also had to set
Inbound Firewall = Allow
Everything started working on my laptop I used as a testbed. Then I setup a VPN Director rule for the Roku and poof, life is good. Bottom line, thank you!

 

[sfx2000]

Asuswrt Merlin: My working OpenVPN configuration for Bi-Directional VPN (router to router, between routers, site to site)

you know - there is a dedicated sub-forum just for questions like this...

Asuswrt-Merlin

Use this forum for posts about all versions of this alternative firmware for ASUS wireless routers

www.snbforums.com

Please be kind - there's a lot of folks that don't care about Asus problems...

 

[elorimer]

Inbound Firewall = Allow

You don't need a bi-directional connection to send a Roku down the tunnel, and I haven't found an inbound rule necessary either. But certain apps on a streamer, particularly Amazon Prime, may need DNS set to "exclusive" if you are out of the country.

 

[Jeff-]

You don't need a bi-directional connection to send a Roku down the tunnel, and I haven't found an inbound rule necessary either. But certain apps on a streamer, particularly Amazon Prime, may need DNS set to "exclusive" if you are out of the country.

I'm not sure if I was clear as I am only 1 cut above an average user. I was referring to the Inbound Firewall setting of Allow that is in VPN -> VPN Client setup page. With out that setting Roku would not connect to the VPN supplied IP.

 

[eibgrad]

I'm not sure if I was clear as I am only 1 cut above an average user. I was referring to the Inbound Firewall setting of Allow that is in VPN -> VPN Client setup page. With out that setting Roku would not connect to the VPN supplied IP.

The purpose of the Inbound Firewall settings (when set to Block) is to prevent someone/something from initiating a connection from the other side of the tunnel (i.e., the OpenVPN server) and into your own network. When connecting to a typical commercial OpenVPN provider, such as your ExpressVPN, there's no need for anyone doing that. The only one who should be initiating connections across the tunnel is YOU, from the OpenVPN client side. You typically only set Inbound Firewall to Allow when YOU (or someone you trust) control the other side of the tunnel, such as site-to-site. You might do this between two homes you own, for example, since you have every intention of allowing connections to be initiated in either direction.

But again, for your typical commercial OpenVPN provider, you would never set Inbound Firewall to Allow. This is too risky since the other side of the tunnel should be assumed untrustworthy. That's why the default is Block.

So I don't know why setting it to Allow in your situation has proven necessary, at least based on everything you've described so far. I suspect there's some missing piece of information that as yet gone unmentioned that might explain it.

 

[Jeff-]

I used the instructions from this link under the Asuswrt-Merlin selection
https://www.expressvpn.com/support/vpn-setup/manual-config-for-asus-router-with-openvpn/#configure
Once I uploaded the .ovpn config file into the router I saw the "Custom Configuration" text box at the bottom was populated (not in screenshot). So, the copy/paste portion of the instructions was skipped.
Also, I used the "Explicit" option also as I only wanted the Roku to use the router VPN.
You know the rest of the story. I sure hope that helps as I really appreciate the help.

 

[eibgrad]

I used the instructions from this link under the Asuswrt-Merlin selection
https://www.expressvpn.com/support/vpn-setup/manual-config-for-asus-router-with-openvpn/#configure
Once I uploaded the .ovpn config file into the router I saw the "Custom Configuration" text box at the bottom was populated (not in screenshot). So, the copy/paste portion of the instructions was skipped.

Nowhere does it tell you to change the Inbound Firewall setting to Allow.

Having been an ExpressVPN user in the past (before they changed to their current ownership), I never needed all those custom configuration options. That's mostly nonsense. The router manages many of those settings on its own, and to add them may even create conflicts. The only exception (iirc) was the fragment option. I found it just wouldn't work without it. But that's a rare exception. In most cases, you can (and probably should) completely ignore anything they suggest adding to the custom config field.

Also, I used the "Explicit" option also as I only wanted the Roku to use the router VPN.
You know the rest of the story. I sure hope that helps as I really appreciate the help.

I assume you meant Exclusive. The Exclusive option does NOT determine who uses the VPN. That responsibility is handled by the VPN Director. The Exclusive option tells the router how to manage DNS, which in this case means the *only* DNS server(s) that should be used while the OpenVPN client is connected is the one(s) provided by the OpenVPN provider. Those DNS servers are pushed by the OpenVPN server to the OpenVPN client when the connection is established. The router then reconfigures its local DNS server (i.e., DNSMasq) w/ those servers as the upstream public DNS servers.

P.S. IIRC, if you're using the VPN Director, Exclusive does NOT use DNSMasq, but bypasses it. Instead, those bound to the VPN w/ the VPN Director are the only ones that use the DNS servers of the OpenVPN provider. All others continue to use the DNS servers of the ISP.

Yeah, it can get really complicated.

 

[ColinTaylor]

I never needed all those custom configuration options. That's mostly nonsense.

Indeed. "route-method exe" is a Windows only option so it's not even applicable for the router.

 

[Jeff-]

Nowhere does it tell you to change the Inbound Firewall setting to Allow.

Having been an ExpressVPN user in the past (before they changed to their current ownership), I never needed all those custom configuration options. That's mostly nonsense. The router manages many of those settings on its own, and to add them may even create conflicts. The only exception (iirc) was the fragment option. I found it just wouldn't work without it. But that's a rare exception. In most cases, you can (and probably should) completely ignore anything they suggest adding to the custom config field.



I assume you meant Exclusive. The Exclusive option does NOT determine who uses the VPN. That responsibility is handled by the VPN Director. The Exclusive option tells the router how to manage DNS, which in this case means the *only* DNS server(s) that should be used while the OpenVPN client is connected is the one(s) provided by the OpenVPN provider. Those DNS servers are pushed by the OpenVPN server to the OpenVPN client when the connection is established. The router then reconfigures its local DNS server (i.e., DNSMasq) w/ those servers as the upstream public DNS servers.

P.S. IIRC, if you're using the VPN Director, Exclusive does NOT use DNSMasq, but bypasses it. Instead, those bound to the VPN w/ the VPN Director are the only ones that use the DNS servers of the OpenVPN provider. All others continue to use the DNS servers of the ISP.

Yeah, it can get really complicated.

Yes, I did mean Exclusive, thank you. Also, it is true "Nowhere does it tell you to change the Inbound Firewall setting to Allow." But I saw it in another example and just tried it and it worked. If I understand you the Exclusive option will make sure DNS is only provided by ExpressVPN, that is a good thing as I don't want DNS requests by the Roku going anywhere else. Also, the custom configuration additions were populated by the .ovpn config file once uploaded into the router. This file was provided by ExpressVPN, should I leave them alone or remove them?
I'm going to provide 8 more screenshots of what I have currently and hope it clarifies my setup. Please let me know if I can provide anything else to help. At this point I want to minimize the time you have been so gracious with and thank you for you efforts so far.

 

[Jeff-]

I only see 5 of 8, not sure why. Here's the other 3

 

[eibgrad]

Yes, I did mean Exclusive, thank you. Also, it is true "Nowhere does it tell you to change the Inbound Firewall setting to Allow." But I saw it in another example and just tried it and it worked. If I understand you the Exclusive option will make sure DNS is only provided by ExpressVPN, that is a good thing as I don't want DNS requests by the Roku going anywhere else. Also, the custom configuration additions were populated by the .ovpn config file once uploaded into the router. This file was provided by ExpressVPN, should I leave them alone or remove them?
I'm going to provide 8 more screenshots of what I have currently and hope it clarifies my setup. Please let me know if I can provide anything else to help. At this point I want to minimize the time you have been so gracious with and thank you for you efforts so far.

By default, when you import a config file, anything that the router does NOT have a direct need for in configuring the GUI is simply dumped into the custom config field, with (as far as I can tell) no regard as to its efficacy. Unfortunately this can lead to conflicts, since if any directive in custom config is a duplicate of that already configured by the router, it will act as an override (whether the router would throw away such a duplicate, I don't know).

So as a general rule, I strongly suggest NOT placing anything into custom config, *even* if the router does so itself. It's a rare exception when it proves necessary. At best, it might be an optimization, something you can add back later, after you know it's working. It just so happens that in the case of ExpressVPN, I'm personally aware that the fragment option was (and I assume still is) necessary. I have no idea if this has had any impact on your apparent need to use Allow for the Inbound Firewall, but just in case it has, that's why I suggested removing everything else from custom config.

All that said, I see nothing else in your configuration that would justify or require the use of Allow for the Inbound Firewall. Why enabling it would make the difference between a working and non-working tunnel for strictly outbound connections escapes me.

 

[eibgrad]

P.S. If you wish to continue pursuing the issue, all I can suggest is dumping the internals, both when Block is specified, then when Allow is specified, and comparing the results. That will often reveal the issue.

ifconfig
brctl show
ip route
ip route show table ovpnc1
ip rule
cat /tmp/etc/openvpn/client1/config.ovpn
iptables -vnL
iptables -t nat -vnL

Feel free to mask your public IP (keys, passwords, etc). Just make it obvious and consistent.

 

[Jeff-]

Bottom line, it works!
I set the Inbound Firewall to Block and deleted the contents of the Custom Configuration.
The client status on the VPN Client page did not show a public IP until I added "fragment 1300" to the Custom Configuration as you said.
I thank you once again and hope this post serves to help others.

 

[lgkahn]

ge did not show a public IP until I added "fragment 1300" t

mine does not show a public ip either.. but not sure it should? as it is site to site and only for access bi-directionally between sites and on both ends the internet does not go down the tunnel?

 

[eibgrad]

mine does not show a public ip either.. but not sure it should? as it is site to site and only for access bi-directionally between sites and on both ends the internet does not go down the tunnel?

@Jeff- should have started his own thread, since this is an old thread, and his problem was never regarding site-to-site anyway. But I just let it slide.

In the situation of a site-to-site tunnel, unless that tunnel is also being used as an internet gateway (typical w/ a commercial OpenVPN provider), I wouldn't expect it to report a public IP. @Jeff-'s problem was simply due to the fact he had the OpenVPN client misconfigured. Once corrected, he got the public IP, as expected.