Maeve at 14:54, 7 July 2025

2025-07-07T14:54:33Z

← Older revision		Revision as of 14:54, 7 July 2025
Line 6:		Line 6:
	Add-DnsClientNrptRule -Comment 'NameOfVPNTunnel' -Namespace '.dnszone.com' -NameServers 203.0.113.0		Add-DnsClientNrptRule -Comment 'NameOfVPNTunnel' -Namespace '.dnszone.com' -NameServers 203.0.113.0
	This works, but the problem is that this rule will always be active. If you know for sure that the device's network situation will never change, this is fine, but if it's a mobile workstation that may be repurposed you should avoid this if possible. We can tell Wireguard to dynamically create and remove these rules using the PostUp and PostDown hooks in the Wireguard config. The problem is that these are disabled by default due to the potential room for abuse. The solution is to enable these using a registry edit:		This works, but the problem is that this rule will always be active. If you know for sure that the device's network situation will never change, this is fine, but if it's a mobile workstation that may be repurposed you should avoid this if possible. We can tell Wireguard to dynamically create and remove these rules using the PostUp and PostDown hooks in the Wireguard config. The problem is that these are disabled by default due to the potential room for abuse. The solution is to enable these using a registry edit:
	~~Set-ItemProperty -Path~~ HKLM:\~~SOFTWARE~~\~~Wireguard -Name~~ DangerousScriptExecution ~~-Type DWord -Value~~ 1		reg add HKLM\Software\WireGuard /v DangerousScriptExecution /t REG_DWORD /d 1 /f

	If this results in "The operation was completed successfully" we can now add these lines to our wireguard config:		If this results in "The operation was completed successfully" we can now add these lines to our wireguard config:
	PostUp = powershell.exe -Command "& { Add-DnsClientNrptRule -Comment 'NameOfVPNTunnel' -Namespace '.dnszone.com' -NameServers 203.0.113.0 }"		PostUp = powershell.exe -Command "& { Add-DnsClientNrptRule -Comment 'NameOfVPNTunnel' -Namespace '.dnszone.com' -NameServers 203.0.113.0 }"
	PostDown = powershell.exe -Command "& { Get-DnsClientNrptRule \| where Comment -eq 'NameOfVPNTunnel' \| foreach { Remove-DnsClientNrptRule -Name $_.Name -Force } }"		PostDown = powershell.exe -Command "& { Get-DnsClientNrptRule \| where Comment -eq 'NameOfVPNTunnel' \| foreach { Remove-DnsClientNrptRule -Name $_.Name -Force } }"

Maeve: Created page with "Sometimes you may have a situation in which you require a machine using a Wireguard tunnel to always use a specific DNS server to resolve specific zones. One case where we needed this was an Active Directory DNS zone that also matched a publicly available DNS zone. The publicly available records resolved to one end of a NAT'd IP range, but the AD DNS zone had records pointing to the other side. When connecting locally in the network, this was fine, but some Windows clien..."

2025-07-03T17:41:01Z

Created page with "Sometimes you may have a situation in which you require a machine using a Wireguard tunnel to always use a specific DNS server to resolve specific zones. One case where we needed this was an Active Directory DNS zone that also matched a publicly available DNS zone. The publicly available records resolved to one end of a NAT'd IP range, but the AD DNS zone had records pointing to the other side. When connecting locally in the network, this was fine, but some Windows clien..."

New page

Sometimes you may have a situation in which you require a machine using a Wireguard tunnel to always use a specific DNS server to resolve specific zones. One case where we needed this was an Active Directory DNS zone that also matched a publicly available DNS zone. The publicly available records resolved to one end of a NAT'd IP range, but the AD DNS zone had records pointing to the other side. When connecting locally in the network, this was fine, but some Windows clients were resolving through the LAN's DNS regardless of the search domain set in the Wireguard config.

To fix this we can leverage the power of the [https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn593632(v=ws.11) Name Resolution Policy Table].

You could simply fix this by executing this command:
Add-DnsClientNrptRule -Comment 'NameOfVPNTunnel' -Namespace '.dnszone.com' -NameServers 203.0.113.0
This works, but the problem is that this rule will always be active. If you know for sure that the device's network situation will never change, this is fine, but if it's a mobile workstation that may be repurposed you should avoid this if possible. We can tell Wireguard to dynamically create and remove these rules using the PostUp and PostDown hooks in the Wireguard config. The problem is that these are disabled by default due to the potential room for abuse. The solution is to enable these using a registry edit:
Set-ItemProperty -Path HKLM:\SOFTWARE\Wireguard -Name DangerousScriptExecution -Type DWord -Value 1
If this results in "The operation was completed successfully" we can now add these lines to our wireguard config:
PostUp = powershell.exe -Command "& { Add-DnsClientNrptRule -Comment 'NameOfVPNTunnel' -Namespace '.dnszone.com' -NameServers 203.0.113.0 }"
PostDown = powershell.exe -Command "& { Get-DnsClientNrptRule | where Comment -eq 'NameOfVPNTunnel' | foreach { Remove-DnsClientNrptRule -Name $_.Name -Force } }"

Force Wireguard DNS Zone Override - Revision history

Maeve at 14:54, 7 July 2025