Add option for Windows/WSL2-compatible WireGuard configs (avoid kill-switch)

[dguido]

Summary

WireGuard for Windows enables restrictive firewall rules (the "kill-switch") when AllowedIPs contains /0 routes. This interferes with WSL2's virtualized network stack, breaking connectivity. Add an option to generate configs that avoid triggering the kill-switch while maintaining full traffic routing.

Background

When a WireGuard peer has AllowedIPs = 0.0.0.0/0 or ::/0, the Windows client adds firewall rules that:

• Restrict DNS queries to configured servers only
• Block traffic that doesn't match expected patterns
• Can interfere with WSL2's virtual network adapter

This is documented in the official WireGuard Windows netquirk.md.

The Workaround

Per WireGuard's documentation, using split routes achieves the same routing coverage without triggering the kill-switch:

Current	Windows-Compatible
0.0.0.0/0	0.0.0.0/1, 128.0.0.0/1
::/0	::/1, 8000::/1

These split routes cover the entire address space but don't activate the firewalling semantics.

Proposed Solution

Add a config option (e.g., windows_compatible_configs: true) that generates WireGuard client configs with split routes instead of /0 routes.

Current (roles/wireguard/templates/client.conf.j2):

AllowedIPs = 0.0.0.0/0,::/0

With option enabled:

AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1

Alternatives Considered

1. Change default for everyone: The split routes are functionally equivalent, but this is a behavioral change that could have unexpected effects on other platforms
2. Documentation only: Users can manually edit configs, but this defeats Algo's ease-of-use goal
3. Generate separate Windows configs: More complex, creates maintenance burden

Related

• PR Wsl2 support for generated configs #14678 (closed) - Attempted this fix but used incorrect IPv6 routes (::/128 instead of ::/1, 8000::/1)
• Issue Split tunneling of WireGuard module #1746 - Split tunneling feature request (different use case - routing only specific subnets)
• Microsoft/WSL#7895 - WSL2 WireGuard connectivity issues
• Microsoft/WSL#5784 - Original report of the workaround