Wsl2 support for generated configs

[Sammers21]

By default generated configs does not allow WSL2 to access network with wireguard enabled. So here is the quick fix for it: microsoft/WSL#7895 (comment)

I guess DNS server must be changed too to 1.1.1.1, does not work without it for me.

[CLAassistant]

All committers have signed the CLA.

[dguido]

Technical Review

Thank you for this PR addressing WSL2 compatibility. I've analyzed the changes and their implications:

What This Change Does

The PR modifies the WireGuard AllowedIPs configuration from:

• 0.0.0.0/0,::/0 (route all traffic through VPN)
• To: ::/128, 0.0.0.0/1, 128.0.0.0/1 (split routing)

Breaking down the changes:

1. IPv6: Changes from ::/0 (all IPv6 traffic) to ::/128 (only the :: address itself)
2. IPv4: Splits 0.0.0.0/0 into two halves: 0.0.0.0/1 (0.0.0.0-127.255.255.255) and 128.0.0.0/1 (128.0.0.0-255.255.255.255)

Why This Helps WSL2

WSL2 has known networking quirks due to its virtualized network stack. This split routing approach is a documented workaround in the WireGuard community that helps avoid conflicts with WSL2's internal networking.

Concerns

1. IPv6 Impact: This change effectively disables IPv6 VPN routing for all users. Only the :: address itself will be routed through the VPN, meaning IPv6 traffic will leak outside the VPN tunnel.

2. Global Change: This affects all WireGuard configurations generated by Algo, not just those intended for WSL2 users.

3. DNS Configuration: You mentioned needing to change DNS to 1.1.1.1, but this change isn't included in the PR.

Recommendation

While this fix helps WSL2 users, applying it globally would break IPv6 VPN functionality for everyone else. Instead, consider:

1. Making this configuration optional during setup (e.g., "Will you use WireGuard on WSL2?")
2. Generating WSL2-specific configuration files alongside standard ones
3. Adding documentation about the IPv6 limitation
4. Addressing the DNS configuration if it's also needed for WSL2

This way, WSL2 users get the fix they need without impacting other users' VPN functionality.

[dguido]

Review Summary

Thank you for working on WSL2 compatibility! Unfortunately, this PR introduces a critical security issue that prevents merging in its current form.

---

🚨 Critical Issue: IPv6 Leak

The change from ::/0 to ::/128 breaks IPv6 routing through the VPN:

Original	Proposed	Effect
::/0	::/128	All IPv6 traffic leaks outside VPN

::/128 only routes the single unspecified address ::, not all IPv6 traffic. This defeats Algo's privacy guarantees for any user on an IPv6-capable network.

---

The IPv4 Change is Fine

The 0.0.0.0/0 → 0.0.0.0/1, 128.0.0.0/1 split is a well-known technique and functionally equivalent.

---

Suggested Fix

If you want to use the split-routing approach for both protocols, the IPv6 equivalent would be:

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

This covers all IPv6 addresses using the same split technique.

---

Additional Concerns

1. Affects all users - This changes every generated client config, not just WSL2 deployments. Consider making this opt-in via a config option.

2. Root cause - Per the linked WSL issue, the original reporter found the actual fix was applying DNS config to the WireGuard server interface, not this client-side workaround.

3. DNS change mentioned but not included - You noted DNS needs to change to 1.1.1.1, but that's not in this PR.

---

Path Forward

I'd suggest one of these approaches:

1. Fix the IPv6 routing in this PR using ::/1, 8000::/1
2. Add a configuration option (e.g., wsl2_compatible) so users can opt-in
3. Document in the wiki as a manual workaround for WSL2 users

Happy to help iterate on this if you'd like to continue working on it!

[dguido]

Closing: IPv6 routing broken

Thank you for identifying this WSL2 compatibility issue. After researching the root cause, I'm closing this PR because the proposed change would break IPv6 VPN routing for all users.

The Problem with This PR

The PR changes AllowedIPs from:

0.0.0.0/0,::/0

to:

::/128, 0.0.0.0/1, 128.0.0.0/1

The IPv6 part is incorrect. ::/128 only routes the :: address itself (effectively nothing), while ::/0 routes all IPv6 traffic. This would disable IPv6 VPN routing for everyone.

The Correct Split-Route Approach

Per the official WireGuard Windows documentation, the correct way to avoid the Windows kill-switch while maintaining full coverage is:

• IPv4: 0.0.0.0/1, 128.0.0.0/1 (as you proposed ✓)
• IPv6: ::/1, 8000::/1 (NOT ::/128 ✗)

Root Cause

The underlying issue is that WireGuard for Windows enables restrictive firewall rules (the "kill-switch") when AllowedIPs contains /0 routes. This interferes with WSL2's virtualized network stack.

Next Steps

I'm filing a separate issue to properly address WSL2 compatibility, which may include:

1. Adding a config option to generate Windows/WSL2-compatible configs with the correct split routes
2. Documentation for WSL2 users explaining the workaround

Thank you for bringing this to our attention!