Hello,
As discussed with R&D, there is a special method that also as workaround:
uci set dhcp.@dnsmasq[0].domainneeded='0'
uci commit dhcp
/etc/init.d/dnsmasq restart
# The following is only needed for firmware version 4.6.x/4.7.x
sed -i '/domain-needed/d' /etc/dnsmasq.conf.vpn
. /usr/bin/route_policy
handle_dns
The first 4 lines executed without issue.
Should
Be either:
/usr/bin/route_policy
or
/usr/bin/route_policy {parameter}
Without the preceeding the ". "
And
handle_dns does not appear to be either a valid paramater to /usr/bin/route_policy or a stand-alone executable/object.
This is not applicable for opal 4.3.x firmware. I've modify Bruce's post.
It's correct for 4.6 and 4.7 firmware.
As I was trying this on a Beryl AX running 4.7.4 all of the workaround instructions were executed.
The bottom line was that there was no change in the resolver behaviour. FQDN would resolve, but those expecting to use the search domain did not.
Would these changes remain following a firmware upgrade?
Would these changes be overwritten after a restore from an earlier backup?
One thing that raised my curiosity is that /etc/dnsmasq.conf.vpn contained a dhcp-range=set referring to IP addresses that are not in my configuration (I.E. 192.68.8.x/24 addresses).
I think it would be useful if you post the command sequence to reverse these changes so I can be certain of getting back to the original configuration.
Yes for /etc/config/dhcp
No for /etc/dnsmasq.conf.vpn
dnsmasq for VPN doesn't work as a DHCP server, that value is ok being a placeholder.
To restore:
uci set dhcp.@dnsmasq[0].domainneeded='1'
uci commit dhcp
/etc/init.d/dnsmasq restart
# The following is only needed for firmware version 4.6.x/4.7.x
cp /rom/etc/dnsmasq.conf.vpn /etc/
. /usr/bin/route_policy
handle_dns
Sorry, I found there was a typo, corrected one is:
uci set dhcp.@dnsmasq[0].domainneeded='0'
uci commit dhcp
/etc/init.d/dnsmasq restart
# The following is only needed for firmware version 4.6.x/4.7.x
sed -i '/domain-needed/d' /etc/dnsmasq.conf.vpn
. /usr/bin/route_policy
handle_dns
Disabling domainneeded will let domain like "some_hostname" to pass to upstream.
some_hostname.lan and some_hostname.local is the same as FQDN, whether they can be forwarded to upstream depends on "option local '/lan/'". They've been supported on firmware 4.7 for clients using VPN.
I have not found this solution to work for the devices I have.
I've had a look at the Beryl AX with the RC 4.8 build and this also does not work.
ssh'ing to the router and looking at the created configs when using the following wg statements:
Snippet from the WG client GUI config file:
[Interface]
Address = 192.168.111.194/32
DNS = 192.168.111.1, example.com
As the the other WG devices I use work, and from the wg-quick help which quotes
"DNS — a comma-separated list of IP (v4 or v6) addresses to be set as the interface's DNS servers, or non-IP hostnames to be set as the interface's DNS search domains."
I would expect to the the following in /tmp/resolv.conf.d/resolv.conf.wgclient1
nameserver 192.168.111.1
search example.com
But I am actually seeing:
nameserver 192.168.111.1
nameserver example.com
Which would explain why this is not working.
Just to note this bug is present in the released 4.8 firmware.
The nameserver can not be a domain; it needs to be an IP for dnsmasq.
To enable forwarding a non-FQDN, you can edit dnsmasq option, uncheck this for vpn dnsmasq instance:
Agreed.
My question is why are the GL-inet devices not creating the correct config files from the uploaded Wireguard configs?
Indeed, we’ll fix this inconsistency for uploaded WireGuard configs.
Thanks.
If search domains start to work I'll be able to use the travel routers for my clients.
Now I have better understanding for search domain, there's option 15 and option 119, and the result for different OS clients the result may vary. We'll investigate this before support this feature.
While you are resolving this bug, can you let me know which parameters you are supporting in resolv.conf?
Thanks
