dnsmasq problem since .3 upgrade

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

kck

Occasional Visitor
I have a pair of RT-88U routers that maintain a permanent vpn between my 2 homes. Router A has the VPN server, B has the client. This has all worked fine for ages. I just upgraded to 386.3 and now name resolution across the tunnel from the A end to nodes on the B end no longer works. I have server=/B/192.168.2.1 on the A end and the log shows that dnsmasq indeed says it will resolve B names with that server. On the B end I have server=/A/192.168.1.1 and also interface=tunxx for the correct tunnel. On the B lan I can resolve name.A just fine. On the A lan however namex.B can't resolve. If from the A lan I do an nslookup and specifically specify the server as 192.168.2.1 it resolves fine which suggests that the B dnsmasq is listening on the interface for requests. Pings/tracerts with actual IP addresses all seem to work ok. If I do an nslookup from a node on A to a name on B I see 2 timeout messages. I'm stumped since this all worked on 386.2. Anyone seen anything that might point me in a useful direction?

Thanks.
 

eibgrad

Very Senior Member
The only thing that comes immediately to mind is perhaps DNS rebind protection in DNSMasq.

If you have this feature enabled on either router (not sure what the default is, or if perhaps that default has changed), it will NOT return a *private* IP for fear of a rebind attack. You can either disable the feature, or better yet, make an exception for B on A.

Code:
# DNSMasq for A
rebind-domain-ok=B

In fact, I just make it a habit to always specify this DNSMasq directive on both sides of any site-to-site VPN, just to avoid any potential problems.
 

kck

Occasional Visitor
Thanks for the suggestion but unfortunately when I tried that it didn't change the outcome. The syslog on router A correctly says "using nameserver 192.168.2.1#53 for domain B" but it doesn't seem to actually be sending the nslookup request there. It just times out. It sort of looks like it is not actually sending the resolution request to the B server even though it says it will.

When I turn on log queries and ping a name on B from a node on A, the A dnsmasq logs that it forwards the query to 192.168.2.1 (i.e. the B router). However, the B dnsmasq never logs that a query for that name was made. Somehow it seems that the query isn't making it to the B dnsmasq. This is driving me nuts because it all worked fine until the upgrade.
 
Last edited:

eibgrad

Very Senior Member
Unless you provide a dump of the relevant config files (esp. DNSMasq), then it's going to be difficult to know what's the problem just based on your description, since it sounds correct. Something is wrong either in DNSMasq or the OpenVPN configs that you're missing.

Just to verify, you can ping and tracert from A to B without issues, the problem is confined solely to DNS lookups.
 

kck

Occasional Visitor
Well the issue was something that was changed between 386.3 and 386.3.2. The remote router had been updated to 386.3 a few days ago when I was physically near it and by the time I got back home here 386.3.2 became available. So this router got updated to that. That's when I saw the problem. Since the remote router is 1000 miles away, I generally hate to upgrade it remotely lest it hiccup (it very rarely does but fixing it it problematic). Nevertheless, I decided to do the remote upgrade and once it was also on 386.3.2 the problem resolved itself. So I have no idea what changed between those version (I quickly scanned the changelog but nothing stood out to me) there clearly was some problem in the original release. I have noticed a number of other recent threads raising issues around vpn on that release so I'd suggest anyone with an anomaly should probably upgrade to the point release to see if that might fix their issue.

Thanks, eibgrad for you effort to assist.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top