Hi, > The problem still is occurring, the service seems to get torn down never > to come back again once the user comes back to the office and connects > back into the main network with ethernet. When the user is on the main > network the VPN host address will not get resolved by DNS by design. We > do not want the user to be on the VPN when they are already on the > internal network. If there's a better way to handle the VPN not > connecting when the non-admin user is on the internal network I'm open > to that too. We use a hostname for VPN server resolution because we use > both IPv4 and IPv6 for host connectivity.
When your laptop is connected to the "main network" and boots, the tunnel service will give up on the DNS resolution failure after a few minutes and exit. The manager service will notice that the service is dead and will clean it up. Hence your tunnel service ceases to exist and doesn't get started on the next boot any more. Split DNS is not the right way to prevent WireGuard tunneling of the on-link traffic. On my devices, I keep the VPN tunnel active all the time. Regardless the network the device is physically connected to. You are not using the IP addresses from your main network subnet for WireGuard clients. So, when you connect your laptop physically into the main network, the NICs' on-link route should be preferred over the route added by WireGuards' AllowedIPs. This makes the local network traffic flow directly. But - and very important for seamless roaming - schedule periodic elevated calls of `wg.exe set vpn.domain.com peer <your VPN peer Base64-encoded pubkey> endpoint vpn.xxxx.org:51820`. It's cheap and can be scheduled to trigger every 2 minutes (and immediately after scheduled time is missed). If your laptop is connected on your main network, WireGuard roaming will learn 192.168.99.1 as the peer endpoint. Then you put your laptop to sleep and wake it up at home in a different network. It will continue to use 192.168.99.1 as peer endpoint, but that's no longer correct. Periodic reset of peer endpoint fixes this. > 2022-01-21 14:00:25.385109: [MGR] Starting at boot WireGuard/0.5.3 > (Windows 10.0.19043; amd64) > 2022-01-21 14:00:25.385617: [TUN] [vpn.domain.com] Starting at boot > WireGuard/0.5.3 (Windows 10.0.19043; amd64) > 2022-01-21 14:00:25.392357: [TUN] [vpn.domain.com] SCM locked for 1s by > .\NT Service Control Manager, marking service as started > 2022-01-21 14:00:25.397054: [TUN] [vpn.domain.com] Watching network > interfaces > 2022-01-21 14:00:25.399865: [TUN] [vpn.domain.com] Resolving DNS names > 2022-01-21 14:00:25.640575: [TUN] [vpn.domain.com] Host not found when > resolving vpn.xxxx.org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:29.648660: [TUN] [vpn.domain.com] Host not found when > resolving vpn.xxxx.org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:33.657345: [TUN] [vpn.domain.com] Host not found when > resolving vpn.xxxx.org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:37.672796: [TUN] [vpn.domain.com] Host not found when > resolving vpn.xxxx.org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:41.682472: [TUN] [vpn.domain.com] Host not found when > resolving vpn.xxxx.org, but no Internet connection available, sleeping > for 4 seconds The on-boot connectivity detection was unreliable and was removed in https://git.zx2c4.com/wireguard-windows/commit/?id=b75cc38c60e36e1117bb40fd4ac78c44f1aae1f6. If SCM started the tunnel service before Dnscache and other networking services, WireGuard couldn't tell from the Windows DNS resolving response whether the resolve failure is transient or not. This fix has not yet been published, but it will not help your tunnel deactivation on split DNS issue. Best regards, Simon
