Connect 2 locations over vpn

[sam_semillia]

Hi,

I am running 2 Asus Routers (RT-AC88U and RT-AX88U) on 2 different geographical locations. Both routers running ASUSWRT-Merlin 384.19_0.
Both routers are running a running DHCP server for their respective location: 1392.168.1.0/24 for first location and 192.168.2.0/24 for second location.
Please see atatched network diagram for details:

What I now would like to accomplish via VPN is the following:

1. Clients should be able to connect to each other by IP
   1. IE: 192.168.1.199 should be able to connect to 192.168.2.150 and vice versa.
2. Clients should be able to connect to each other by NAME
   1. IE: Clientname2 should be able to connect to Client123 and vice versa.

Can someone please help me?

Thanks and BR

 

[eibgrad]

Just configure the OpenVPN server and client as you'd expect for a unidirectional tunnel. But in the case of the OpenVPN server, in order to make it "site to site" (i.e., bidirectional), you'll want to add under the Manage Client Specific Options, an entry for 192.168.2.0 255.255.255.0, using the CN (Common Name) as specified on the OpenVPN client's cert. Do NOT push it, just specify it.

 

[Jeffrey Young]

You can check this thread as well;

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

 

[sam_semillia]

By now, I came so far:

Server:





Client:




Now I can connect via IP to IP!
But I can not conenct NAME to NAME?!

Anything I am missing out here?

Thanks, BR

 

[eibgrad]

Name resolution will only work if the tunnel's network interface name (e.g., tun21) is added to DNSMasq. IOW, DNSMasq by default is NOT listening to that network interface, only the default network (br0).

interface=tun*

The '*' is a wildcard, which makes things a bit simpler. But you could specify tun21 specifically if you are sure this is correct.

You need to add that line to the DNSMasq config using a custom config file.

Custom config files

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[sam_semillia]

Thanks! But do I need to add it on client or on server side?

I DO not have any file in folder /jffs/configs! However, I'll create dnsmasq.conf.add with a single line:
interface=tun*


Is that correct?

Thanks a lot!
BR Franz

 

[eibgrad]

Thanks! But do I need to add it on client or on server side?

I DO not have any file in folder /jffs/configs! However, I'll create dnsmasq.conf.add with a single line:
interface=tun*


Is that correct?

Thanks a lot!
BR Franz

I'm assuming the OpenVPN server is NOT adding its own network interface name to DNSMasq, but to be honest, I've never checked if that's the actually case. If it is, then name resolution should work client to server. But it's seem unlikely the OpenVPN client would similarly and automatically add its own network interface (e.g., tun11) to DNSMasq on its side. And so the problem may only exist in one direction, server to client.

In order to use custom scripts and/or config files, you need to enable JFFS and JFFS custom scripts under Administration->System. And if necessary, create the /jffs/config directory to contain the file w/ the configuration changes.

 

[sam_semillia]

I added file "dnsmasq.conf.add" in folder "/jffs/configs" in Server, set "Enable JFFS custom scripts and configs" to "YES" and rebooted.

Still, server to client does not work to acces the network via the NAME. Any other ideas? :/

Thanks for your efforts!

Br

 

[eibgrad]

In order for the server to access the DNS server of the client, the *client* must have its tunnel's network interface name added (tun21 tun22, etc., or tun*) to DNSMasq on its side. I just checked, and by default, the OpenVPN client definitely doesn't do this by default.

 

[eibgrad]

One other thing. The server also has to know to use the DNS server on the client side when those devices are referenced. You typically do this by adding a server directive to DNSMasq on the server side that directs queries to the client's DNS server based on the domain name used by the client.

server=/client_side_domain/192.168.2.1

I don't recall you taking this step.

The reverse is also true. The client needs to know to use the DNS server on the server side when those devices are referenced. Similarly, you add that directive to DSNMasq on the client side.

server=/server_side_domain/192.168.1.1

If that wasn't complicated enough, DNSMasq is typically configured to prevent rebind attacks, which means it won't accept queries that return IPs in the private IP space! So you also need to add exceptions for those as well in DNSMasq.

# client side
rebind-domain-ok=server_side_domain

# server side
rebind-domain-ok=client_side_domain

Yes, setting up DNS across a site-to-site tunnel is trickery than you might expect.

 

[eibgrad]

Btw, did you push the DNS server on the server side to the client? In a normal site-to-site config, this is NOT what you would do. And if client to server is working, this may be the reason.

 

[sam_semillia]

Yes, setting up DNS across a site-to-site tunnel is trickery than you might expect.

indeed it is... That's what the files and the setups currently look like:

DNSMASQ


Server


Client


Is that correct?

BTW: With this configuration, a SERVER side computer can NOT PING any computer from the CLIENT side.

Thanks BR

 

[sam_semillia]

I added domains to the respective networks:
Server: VOE
Client: OBW

Then I changed the config files to:

CLIENT
/jffs/configs/dnsmasq.conf.add
interface=tun*
server=/voe/192.168.1.1
rebind-domain-ok=voe

--> service restart_dnsmasq

SERVER
/jffs/configs/dnsmasq.conf.add
interface=tun*
server=/obw/192.168.2.1
rebind-domain-ok=obw

-->service restart_dnsmasq


Now, I can go from client to server, but NOT from server to client

Thanks so far, you already helped me a lot!
Looking forward for your ideas for the remaining problem

Thanks, BR

 

[eibgrad]

As I said before, in a site-to-site config, you do NOT push the server's DNS server to the client. That creates a circular reference! The client is trying to resolve its own names by referencing back to the server's DNS server. And according to your images, you appear to be doing just that; pushing the server's DNS server to the client (Advertise DNS to clients).