Running a slate 7 @ 4.9.2 with both Wireguard obfuscation, and Openvpn clients configured. I start either VPN client up and it connects to the “home” Brume3 (4.9) and all appears well. Brume3 local host names all work, I can access devices. PiHole at “home” works fine.
Then I try to access the slate7 via its host.domain and it is not resolved. I can access it via IP just fine. So I start looking around and Luci, but ONLY with the VPN ACTIVE, presents NETWORK→DHCP and DNS→OVPNCLIENT1 where I can fill in “resolve locally” and “domain”. Cool I thought. I filled them in hit “Save and Apply”. I can access the slate7 via the host.domain I expect. The trouble is, if I stop and start the VPN the values are back at the default. All of this applies to the Wireguard VPN as well. Once the values are reset I can reference the slate7 via hostname.local where hostname is what I have specified elsewhere. Without either VPN active I can access the slate7 via hostname.domain as specified in my parameters.
I tried slate7.local and it resolved to the client router with either vpn active. BTW I tested this while logged into the slate7 via IP address.
I suspect that the saved values are ignored when the VPNs are started.
Hi,
Thank you for the report.
The current firmware sets the local and domain options to /lan/ and lan by default when creating VPN dnsmasq instances. These values are not inherited from the main dnsmasq instance. Therefore, they will be reset whenever the tunnel protocol is changed or the tunnel is deleted and recreated.
As a workaround, you can run the following commands to modify the initialization script so that new VPN dnsmasq instances inherit the local and domain settings from the main dnsmasq instance. You will then only need to update the settings on the main instance:
SCRIPT_PATH=/usr/bin/setup_instance
ROM_SCRIPT=/rom/usr/bin/setup_instance
sed -i \
-e "s# uci set dhcp.\${instance_type}\${index}.local='/lan/'# uci set \"dhcp.\${instance_type}\${index}.local=\$(uci -q get dhcp.@dnsmasq[0].local || echo /lan/)\"#" \
-e "s# uci set dhcp.\${instance_type}\${index}.domain='lan'# uci set \"dhcp.\${instance_type}\${index}.domain=\$(uci -q get dhcp.@dnsmasq[0].domain || echo lan)\"#" \
"$SCRIPT_PATH"
if ! sh -n "$SCRIPT_PATH" ||
! grep -Fq 'local=$(uci -q get dhcp.@dnsmasq[0].local || echo /lan/)' "$SCRIPT_PATH" ||
! grep -Fq 'domain=$(uci -q get dhcp.@dnsmasq[0].domain || echo lan)' "$SCRIPT_PATH"; then
cp -p "$ROM_SCRIPT" "$SCRIPT_PATH"
echo 'Patch failed; the original script has been restored.'
else
main_local="$(uci -q get dhcp.@dnsmasq[0].local)"
main_domain="$(uci -q get dhcp.@dnsmasq[0].domain)"
[ -n "$main_local" ] || main_local='/lan/'
[ -n "$main_domain" ] || main_domain='lan'
for instance in $(uci -q show dhcp | sed -n 's/^dhcp\.\(wgclient[1-5]\|ovpnclient[1-5]\)=dnsmasq$/\1/p'); do
uci set "dhcp.$instance.local=$main_local"
uci set "dhcp.$instance.domain=$main_domain"
done
uci commit dhcp
/etc/init.d/dnsmasq restart
echo 'Local-domain settings were synced to the VPN DNS instances.'
fi
You can verify the resulting values with:
uci show dhcp | grep -E '^dhcp\.(wgclient|ovpnclient)[1-5]\.(local|domain)='
To remove the modification later and restore the script supplied with the firmware, run:
cp -p /rom/usr/bin/setup_instance /usr/bin/setup_instance
sh -n /usr/bin/setup_instance
The modification will continue to work after the router is rebooted. However, it will not be preserved after a firmware upgrade, so you will need to run the commands again.
Thank you Will, I’d rather avoid having to install a script so I will live with it. It’s not that big a deal to me since the VPN dnsmasq parameters are preserved over a power cycle. However it is a genuine nuisance when debugging.
I take it from the remarks that this is not something that is concidered a bug? The reason I consider it as such is because the word SAVE implies a bit of persistance in my mind. All of the other parameters associated with the VPN (or tunnel if you prefer) are preserved across a stop/start of the VPN.
Hi,
Can I give a feature suggestion for this?
It can be a small one via the GL-iNet ui although with the new vlan/interface design it might need to be put somewhere else including the static leases which i also requested earlier more to some global dhcp option section.
What I want is a checkbox which makes the dhcp the primary dhcp server on the network.
If the checkbox is not checked, then for dnsmasq authoritative dhcp gets unchecked, and the /lan/ gets removed, there could also be some informative text if a upstream dhcp holds lan as domain authority it will not resolve and conflict.
There could also be a optional textbox for lan but only if it is checked otherwise greyed out.
I have tested this with luci and it works perfect, the field can be just left out which is better than changing it.
Thanks for the suggestion. We’ll discuss adding these DHCP and local-domain controls to the GL.iNet interface with the product team.
I am not exactly sure what is being suggested with the check box, but I do not necessarily subscribe to the notion that the check box on the VPN CLIENT would control the network authoritive DHCP, and DOMAIN name, given the client may have the remote network “pushed” to it? Exactly what are the borders of the network being discussed?
It shows I am not a network engineer but how can there be two authoritive DHCPs, one for the WGclient and one for the Base/Slate7?