Skip to content

Allow traffic towards private internal endpoints via WireGuard #593

Closed

Description

@qdrop17

VpnRoutes.EXCLUDED_RANGES hardcodes 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 as excluded from the tun. Setting AllowedIPs = 0.0.0.0/0 in WireGuard doesn't help — it only feeds wireguard-go's UAPI, never VpnService.Builder.addRoute(), which reads exclusively from VpnRoutes.getRoutes().

I run a split-DNS setup: my VPN's resolver hands back RFC1918 addresses for some hostnames (services I host at home, behind the WireGuard endpoint). Those hosts are only reachable through the tunnel, but they land in the excluded gap and get pushed out over the underlying network, where they're unreachable. Lookup succeeds (the DNS host gets re-injected as a /32), connection times out — confusing.

This isn't an edge case. Plenty of privacy-conscious users self-host things at home and want to reach them while TC is running. On Android you can't run a second VPN alongside TC, so there's no workaround.

I built the app from master with the three RFC1918 entries removed and it works flawlessly for me.

diff --git a/app/src/main/java/eu/faircode/netguard/VpnRoutes.java b/app/src/main/java/eu/faircode/netguard/VpnRoutes.java
index 29430d6..846bfb8 100644
--- a/app/src/main/java/eu/faircode/netguard/VpnRoutes.java
+++ b/app/src/main/java/eu/faircode/netguard/VpnRoutes.java
@@ -43,12 +43,9 @@ public class VpnRoutes {
     private static final String[][] EXCLUDED_RANGES = {
             // Reserved and private ranges
             {"0.0.0.0", "8"},       // Current network (RFC 1122)
-            {"10.0.0.0", "8"},      // Private (RFC 1918)
             {"100.64.0.0", "10"},   // CGNAT (RFC 6598)
             {"127.0.0.0", "8"},     // Loopback (RFC 1122)
             {"169.254.0.0", "16"},  // Link-local (RFC 3927)
-            {"172.16.0.0", "12"},   // Private (RFC 1918)
-            {"192.168.0.0", "16"},  // Private (RFC 1918)
             {"224.0.0.0", "3"},     // Multicast (224/4) + reserved (240/4)
 
             // T-Mobile Wi-Fi calling

Trade-off: a host on the local LAN (the Wi-Fi router the phone is currently on) would also get pulled into the tunnel — arguably what the user asked for with AllowedIPs = 0.0.0.0/0, and VpnService.protect() still handles Wi-Fi calling.

Would this be acceptable, or would a toggle be preferable?

Activity

  1. kasnder commented on Jul 9, 2026

    @kasnder
    Member

    So you have private IPs behind the VPN? Interesting!

    Obviously, the reason to implement it this way is to make things easy for the average user of the app..

  2. nmarteybotchway commented on Jul 12, 2026

    @nmarteybotchway
    Collaborator

    Hi - I'd be interested in working on this

  3. added a commit that references this issue on Jul 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions