Asuswrt Merlin, resolve client lan names on server-side?

[nadieaqui]

Asuswrt Merlin:
I have a bidirectional OpenVPN connection running on 2 Asuswrt Merlin routers (firmware is current).
But, I cannot perform a "nslookup pc.client.lan" on the OpenVPN Server?
What I would like to do is resolve client lan names on the server.
Does anyone know of a solution?
[I spent several days searching and trying but could not find a solution]

server lan: 192.168.0.x
client lan: 192.168.1.x

Here is what I can do:
client> nslookup pc.server.lan
client> ping pc.server.lan
server> ping ip-client-lan (e.g. 192.168.1.25)

Here is what I *cannot* do:
server> nslookup pc.client.lan
server> ping pc.client.lan

 

[eibgrad]

Make sure DNSMasq is configured on both sides w/ the following directive.

interface=tun*

This tells the DNS servers to listen for queries from the OpenVPN tunnel's network interface. By default, they will only listen to the default network interface (br0).

 

[nadieaqui]

Make sure DNSMasq is configured on both sides w/ the following directive.

interface=tun*

This tells the DNS servers to listen for queries from the OpenVPN tunnel's network interface. By default, they will only listen to the default network interface (br0).

That was the solution. Thank You!

 

[nadieaqui]

Make sure DNSMasq is configured on both sides w/ the following directive.

interface=tun*

This tells the DNS servers to listen for queries from the OpenVPN tunnel's network interface. By default, they will only listen to the default network interface (br0).

I upgraded the Client to Merlin 384.16.
And,
1) I have "interface=tun*" in DNSMasq on both server and client.
2) Client has "Inbound Firewall" = Allow

However, the OpenVPN server cannot resolve client lan names.
Here is what I *cannot* do:
server> nslookup pc.client.lan
server> ping pc.client.lan

[FYI: before posting, I tried searching but could not find a solution]
Does anyone know of a solution?

 

[nadieaqui]

I upgraded the Client to Merlin 384.16.
And,
1) I have "interface=tun*" in DNSMasq on both server and client.
2) Client has "Inbound Firewall" = Allow

However, the OpenVPN server cannot resolve client lan names.
Here is what I *cannot* do:
server> nslookup pc.client.lan
server> ping pc.client.lan

[FYI: before posting, I tried searching but could not find a solution]
Does anyone know of a solution?

Solved. Add client domain name (client.lan) and its DNS server (192.168.1.1) to Server DNSMasq; Client has "Inbound Firewall" = Allow; and reboot server.

For example, in dnsmasq.conf.add on OpenVPN Server -- I have the following lines
interface=tun*
server=/client.lan/192.168.1.1

now, this works.
server> nslookup pc.client.lan
server> ping pc.client.lan

 

[kinglevel]

thnk gd for this thread...

 

[AlexHK]

If DNS rebind protection is enabled (WAN>Enable DNS rebind protection) it needs to be disabled for this to work, or probably safer 'whitelist' the domain with the rebind-domain-ok option in /jffs/configs/dnsmasq.conf.add:

interface=tun*
server=/client.lan/192.168.3.1
rebind-domain-ok=/client.lan/

 

[RMerlin]

If DNS rebind protection is enabled (WAN>Enable DNS rebind protection) it needs to be disabled for this to work, or probably safer 'whitelist' the domain with the rebind-domain-ok option in /jffs/configs/dnsmasq.conf.add:

interface=tun*
server=/client.lan/192.168.3.1
rebind-domain-ok=/client.lan/

That shouldn't be necessary, as rebind protection only applies to replies coming from the upstream servers, not for those locally resolved by dnsmasq. Otherwise LAN resolution wouldn't work for anyone that uses rebind protection.

 

[AlexHK]

That shouldn't be necessary, as rebind protection only applies to replies coming from the upstream servers, not for those locally resolved by dnsmasq. Otherwise LAN resolution wouldn't work for anyone that uses rebind protection.

Seems dnsmasq considers 192.168.3.1 as upstream server, for which the rebind protection kicks in if enabled.

man dnsmasq:

--server=[/[<domain>]/[domain/]][<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
Specify IP address of upstream servers directly. Setting this flag does not suppress reading of /etc/resolv.conf, use -R to do that. [...]

If rebind protection is enabled and I don't use rebind-domain-ok=/client.lan/ the router logs possible DNS-rebind attack detected: host.client.lan and it won't resolve when I use nslookup for xxx.client.lan.

 

[RMerlin]

Seems dnsmasq considers 192.168.3.1 as upstream server, for which the rebind protection kicks in if enabled.

If you use an internal DNS server for local name resolution rather than the router itself then yes, it will become subject to rebind protection.

 

[AlexHK]

If you use an internal DNS server for local name resolution rather than the router itself then yes, it will become subject to rebind protection.

Just to clarify, the router is doing the DNS, no other server.

Router #1: 192.168.0.1 server.lan
dnsmasq.conf: server=/client.lan/192.168.3.1 (= send DNS queries for client.lan to 192.168.3.1 which is the router at the other end of the VPN tunnel)

Router #2: 192.168.3.1 client.lan
dnsmasq.conf: server=/server.lan/192.168.0.1 (= send DNS queries for server.lan to 192.168.0.1 which is the router at the other end of the VPN tunnel)

With rebind protection enabled nslookup returns nothing and rebind warning shows up in the log. With rebind protection disabled it works.

Now with rebind-domain-ok=/client.lan/ and rebind-domain-ok=/server.lan/ in the dnsmasq.conf.add it works also with rebind protection enabled.

No idea why my two routers show this behaviour. I am on fw 386.7_2.

Either way, it works the way it is now.

Maybe sooner or later somebody else with name resolution working across the VPN and without these rebind-domain-ok directives could chime in and report what happens if they enable rebind protection momentarily.

I am glad it's working on my end due to this thread with brilliant info.