Scribd
Upload
2 views1 page

I Network Routing

The document discusses the implications of using `IP_UNICAST_IF` with `/0` allowed IPs in Windows, highlighting that it forces packets over the default route interface without a workaround from Microsoft. It details the 'kill-switch' mechanism that WireGuard implements to prevent traffic leakage when a `/0` allowed IP is present, including specific firewall rules. Alternatives to using `/0` are provided to avoid restrictive semantics while maintaining similar routing functionality.

Uploaded by

Vig store3
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2 views1 page

I Network Routing

The document discusses the implications of using `IP_UNICAST_IF` with `/0` allowed IPs in Windows, highlighting that it forces packets over the default route interface without a workaround from Microsoft. It details the 'kill-switch' mechanism that WireGuard implements to prevent traffic leakage when a `/0` allowed IP is present, including specific firewall rules. Alternatives to using `/0` are provided to avoid restrictive semantics while maintaining similar routing functionality.

Uploaded by

Vig store3
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

routed over a non-default route interface, the use of `IP_UNICAST_IF` forces the

packets to, in fact, go over the default route interface. This is problematic, but
at this moment, Microsoft has not provided a viable workaround. If any allowed IPs
are a `/0`, then the interface is given a `0` metric and Windows' [automatic metric
logic]([Link]
atic-metric-for-ipv4-routes) is disabled.

### Firewall Considerations for `/0` Allowed IPs

If an interface has only one peer, and that peer contains an Allowed IP in `/0`,
then WireGuard enables a so-called "kill-switch", which adds firewall rules to do
the following:

- Packets from the tunnel service itself are permitted, so that WireGuard packets
can flow successfully.
- If the configuration specifies DNS servers, then packets sent to port `53` are
only permitted if they are to one of those DNS servers. This is to prevent Windows'
[ordinary multihomed DNS resolution
behavior]([Link]
server-2008-R2-and-2008/dd197552%28v%3Dws.10%29), so that DNS queries only go to the
DNS server specified, rather than multiple DNS servers.
- Loopback packets are permitted, and packets actually going through the WireGuard
tunnel are permitted.
- DHCP for IPv4 and IPv6 and NDP for IPv6 are permitted.
- All other packets are blocked.

This prevents traffic from leaking outside the tunnel.

If you'd like to use a default route _without_ having these restrictive kill-switch
semantics, one may use the routes `[Link]/1` and `[Link]/0` in place of
`[Link]/0`, as well as `::/1` and `8000::/1` in place of `::/0`. This achieves
nearly the same thing, but does not activate the above firewalling semantics. And
users without the need for a `/0` route at all do not have to worry about this, and
instead fall back to ordinary Windows routing and DNS behavior.

### Considerations for non-`/0` Allowed IPs

You might also like