Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Excluded IPs to client peer specification #158

Open
nicksimonov opened this issue Jan 5, 2025 · 8 comments
Open

Add Excluded IPs to client peer specification #158

nicksimonov opened this issue Jan 5, 2025 · 8 comments
Labels
enhancement New feature or request

Comments

@nicksimonov
Copy link

nicksimonov commented Jan 5, 2025

Right now the only way to control which IPs are going through a tunnel is with an AllowedIPs list of networks.

However, the most typical need is to allow everything except a certain private range. If we want to create a list of all IPs except, say 192.168.0.0/24, the list is going to be very long and for some people not easy to create or understand. It would be much easier for the user and more efficient for processing if we add an ability to specify something like:

[Peer]
AllowedIPs = 0.0.0.0/0
ExcludedIPs = 192.168.0.0/16

The logic would be to check first that the IP is in Allowed list and then if it is not excluded

@nicksimonov nicksimonov added the enhancement New feature or request label Jan 5, 2025
@codebymikey
Copy link

There's a typo in the proposed spec.

-ExcudedIPs = 192.168.0.0/16
+ExcludedIPs = 192.168.0.0/16

This is a big quality of life improvement for users without needing a complexly long list of IPs to easily support specific whitelisted IPs.

Additional background information for the issue: https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/

@nicksimonov
Copy link
Author

There's a typo in the proposed spec.

-ExcudedIPs = 192.168.0.0/16
+ExcludedIPs = 192.168.0.0/16

Corrected, thank you

@nicksimonov
Copy link
Author

As a less generic but somewhat easier for the user alternative to ExcludedIPs list (or maybe in addition to), the client can exclude all the main private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) by default unless overwritten somehow in the config file

@dulitz
Copy link

dulitz commented Jan 14, 2025

AllowedIps per se don't control routing. Tools like wg-quick (and this one) do use AllowedIps for outbound routing, which works most of the time but as the wg-quick man page notes, not all the time.

Isn't the usual way of addressing this issue to create a specific route in the routing table, i.e. ip route add 10.0.0.0/8 via [some IP on a connected interface]? Why is that not working here?

@nicksimonov
Copy link
Author

We are talking about client configuration. It's not realistic to ask the user to configure a routing table on Android phone or iPhone.

One of the use-case scenarios is for a user who installs Wireguard on a phone and want to mirror the screen to a TV. To make it work the user needs to exclude his local network from the Wireguard tunnel.

@dulitz
Copy link

dulitz commented Jan 14, 2025

You know you're commenting on an issue opened with wireguard-vyatta-ubnt? No one involved in client code reads these issues.

@nicksimonov
Copy link
Author

nicksimonov commented Jan 14, 2025

You know you're commenting on an issue opened with wireguard-vyatta-ubnt? No one involved in client code reads these issues.

Do you know the proper place for this suggestion? Android section does not appear to have issues open. In any case, the suggestion is valid for any peer configuration

@dulitz
Copy link

dulitz commented Jan 14, 2025

Sorry I don't. https://github.com/WireGuard/ shows a bunch of projects, many of which at least include non-router clients like Android. But those are only mirrors and they appear not to have issues enabled.

Probably https://lists.zx2c4.com/mailman/listinfo/wireguard would be my best suggestion. Good luck.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

3 participants