celzero
LAN Inbound Connections Fail to Route Correctly when VPN Isolation Mode is Enabled (Likely NAT Hairpinning/Loopback Issue)
rethink v0.5.5t Android 11/12/14/9/
Problem Description
I primarily use Rethink DNS to leverage its firewall capabilities to isolate and restrict applications (e.g., LocalSend) that perform aggressive unicast scanning of the entire local area network (LAN) for network fingerprinting. I aim to limit their access to a very small, defined set of subnets.
Steps to Reproduce
Configure LocalSend application with Isolation Mode enabled.
Set the firewall rules to ALLOW the following specific LAN subnets only:
192.168.0.0/27 (A small subset of my LAN) 255.255.255.255 (Broadcast) 224.0.0.0/4 (Multicast) 169.254.0.0/16 (Link-local)
On the Android phone (LocalSend), verify outbound connectivity: Success. The phone can correctly discover and communicate with the PC.
On the PC, attempt to discover the Android phone: Failure. The PC cannot find the phone.
Analysis of Routing Failure
The failure is isolated to inbound connections from the LAN (PC to Android). The incoming request is likely being misrouted or dropped after being intercepted by the VPN tunnel.
| Test Configuration | PC Discovers Phone? | Observation |
|---|---|---|
| 1. Initial Setup (Isolation ON, Custom Subnets) | NO | Inbound routing fails. |
| 2. App Bypass Firewall | NO | Bypassing firewall rules does not resolve the underlying routing issue. |
| 3. Exclude App (Exclude from VPN) | YES | Traffic bypasses VPN tunnel, uses physical interface, works correctly. |
| 4. Enable Experimental Option | YES | Revert to Step 1, but enable "Do not route Private IPs (experimental)". This works, but sacrifices firewall control over the 192.x.x.x range. |
Core Suspected Issue (VPN Hairpinning)
When a VPN-based firewall is active, all private IP traffic (e.g., 192.168.x.x) is typically hijacked into the virtual tun interface (often the 10.x.x.x range).
The incoming LAN packet from the PC enters the phone via the physical Wi-Fi interface, is intercepted by the VPN framework, but then fails to correctly "hairpin" or loop back from the virtual tun interface back to the application (LocalSend) listening on its local port.
Comparison with NetGuard
I tested with NetGuard (another VPN-based Android firewall). NetGuard successfully monitors the LocalSend LAN scanning activity while simultaneously allowing the PC-to-Android inbound discovery to work normally.
This suggests that a mechanism exists in VPN-based firewalls to: Intercept and filter outbound LAN traffic (to enforce firewall rules). Simultaneously ensure that inbound LAN connections correctly reach the target application.
Request for Assistance
Is it possible to implement a Policy Routing / NAT Hairpinning mechanism within Rethink DNS that:
Maintains the validity of the firewall blocking rules for outbound LAN scanning (traffic must pass through the VPN tunnel for filtering).
Concurrently allows inbound traffic originating from the external LAN to be correctly re-routed/injected back to the Android application's local loopback interface?
Conclusion and Call to Action
I have reviewed all relevant issues concerning P2P/mDNS and Android VPN routing limitations. I understand that this challenge likely stems from the Android VPN framework's inherent difficulty in handling inbound connections, potentially due to a lack of relevant public APIs to facilitate LAN inbound routing/hairpinning.
However, the functional behavior observed in NetGuard provides a strong indication that a solution is possible. Based on technical consultations, the hypothesized methods NetGuard might employ include:
Sophisticated Per-App Split Tunneling: Utilizing fine-grained kernel routing operations to ensure that while LAN traffic is received on the VPN interface, the response traffic is correctly routed back out through the physical Wi-Fi interface.
Transparent Proxy/Firewall Mode: Working as a transparent layer within the Android network stack to monitor and log traffic without fully hijacking the LAN routing path.
Inbound NAT Hairpinning: Implementing complex Network Address Translation (NAT) rules within the VPN to redirect or "re-inject" LAN packets arriving at the virtual interface to the application's actual listening port.
I earnestly request that the Rethink DNS maintainers investigate a solution, drawing hope from NetGuard's proven capability. The goal is to leverage Netfilter rules or advanced routing strategies to resolve the inbound connection hairpinning problem.
Crucially, the motivation for fixing this routing issue is not merely to ensure P2P software availability, but to establish effective defense against privacy-infringing behavior (specifically, malicious LAN scanning and network fingerprinting) while maintaining the functionality of necessary local services.
Why the "Do not route Private IPs (experimental)" is Unacceptable
I must emphasize that enabling the "Do not route Private IPs (experimental)" option is not a viable solution.
Excluding LAN traffic from the VPN tunnel essentially means the core goal—to isolate malicious applications from performing network fingerprinting scans—is completely defeated. My primary requirement is to block these apps' LAN scanning behavior while simultaneously allowing them to access the internet.
Unfortunately, many proprietary vendor applications I deal with exhibit this aggressive LAN scanning behavior but still require external internet connectivity. I cannot simply use Isolation Mode to block them from the internet entirely. If I enable "Do not route Private IPs (experimental)" to solve the inbound routing issue, I am simultaneously allowing these applications to freely collect network fingerprints. This renders the firewall defenseless against the specific privacy violation I am trying to prevent, which fundamentally contradicts the purpose of using Rethink DNS.
Therefore, the necessary solution must fix the inbound connection routing/hairpinning issue while maintaining full firewall oversight of local traffic.
don't use ai slop to write your excuse
Then I use half-hanging English?
use your native non English language instead
don't use ai slop to write your excuse
Then I use half-hanging English?
use your native non English language instead
我怎么觉得你比我用的AI更像AI回复？
don't use ai slop to write your excuse
Then I use half-hanging English?
use your native non English language instead
我怎么觉得你比我用的AI更像AI回复？
I have used generative ai before and your answer look like it ai tends to have long winded verbose answer
don't use ai slop to write your excuse
Then I use half-hanging English?
use your native non English language instead
我怎么觉得你比我用的AI更像AI回复？
I have used generative ai before and your answer look like it ai tends to have long winded verbose answer
我自己写了之后让AI帮我总结翻译的英文，半吊子英文加上不熟悉网络术语，就让AI给注意改进了专业术语准确性。
I'm closing my old issue #1159 as I think you are describing the same problem in a more accurate and comprehensive way. It is happening to any app and with any type of inbound connection (HTTP, FTP etc). So it is not a MixPlorer or an SMB only issue.
