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.