search

celzero / rethink-app

DNS over HTTPS / DNS over Tor / DNSCrypt client, WireGuard proxifier, firewall, and connection tracker for Android.
https://rethinkfirewall.com/
Apache License 2.0
2.84k stars 145 forks source link

VPN routes not set as expected with WireGuard #1546

Open ignoramous opened 3 months ago

ignoramous commented 3 months ago

I was just about to raise my own issue which I think is a duplicate of this:

My local wi-fi connection and my WireGuard host both have IPv6 connectivity; my mobile internet does not. I have a WireGuard proxy enabled in Simple mode, routing only internal IP addresses (IPv4 and IPv6). Choose IP version is set to Auto.

Whilst on wi-fi, I can resolve and connect to domains via IPv6 as expected. When I disconnect from the wi-fi and switch to mobile data, Rethink still appears to be trying to connect to any hosts via IPv6, despite the mobile network not supporting this. Setting Choose IP version back to IPv4 correctly prevents the use of IPv6. Disabling the proxy and using the same DNS over direct DoH also correctly sticks to IPv4.

📎 2024-06-14-14-09-17_245.log

With Termux attempting curl https://example.com in a loop, it resolved the DNS to IPv4 first but then switched to IPv6 after a second DNS resolution -- looks like it takes whichever of IPv4 and IPv6 resolve first, and for me IPv6 seems to be winning more often.

If Rethink is set to Configure -> Network -> Auto, you can check the footer of the bottomsheet that comes up when you tap on the downward-arrow next to the STOP/START button on the homescreen to check if Rethink is routing v4+v6.

"protos: IPv4" on mobile data, so it is correctly detecting that IPv6 is unavailable.

Originally posted by @Terrance in https://github.com/celzero/rethink-app/issues/1532#issuecomment-2168506535

Terrance commented 3 months ago

Pulling over existing observations from #1532...

ifconfig via adb On wi-fi: ``` tun1 Link encap:UNSPEC inet addr:10.111.222.1 P-t-P:10.111.222.1 Mask:255.255.255.0 inet6 addr: fd66:f83a:c650::1/120 Scope: Global inet6 addr: fe80::4e8f:6956:f0dc:9950/64 Scope: Link UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:1558 errors:0 dropped:0 overruns:0 frame:0 TX packets:1191 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:539681 TX bytes:120086 ``` On mobile data: ``` tun0 Link encap:UNSPEC inet addr:10.111.222.1 P-t-P:10.111.222.1 Mask:255.255.255.0 inet6 addr: fe80::ebc3:9877:587c:b35b/64 Scope: Link UP POINTOPOINT RUNNING MTU:1280 Metric:1 RX packets:69 errors:0 dropped:0 overruns:0 frame:0 TX packets:88 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:5108 TX bytes:19466 ```

Whilst recording the log above, the Network logs screen showed the IPv4 for the first handful of requests, and then started showing the IPv6 address instead when the requests started failing. The DNS logs screen showed requests for both IPv4 and IPv6, but for the first set of requests the IPv4 answer came in first, and for the second set the IPv6 answer came first.

Another go with very verbose debugging: 📎 2024-06-14-20-55-54_989.log

Disconnected from wi-fi at around 20:56:00 (UTC+1), but requests continued to be tried via IPv6: img1: img2:

The four DNS logs pictured, oldest to newest, are (v4, v6), (v6, v4) -- the one that comes in first varies each time.

ignoramous commented 3 months ago

Thanks. Can confirm the bug.

Rethink's built-in 4to6 translation is kicking in :facepalm:

1718394955.130 10506 6065 15348 I GoLog : common.go:31: D intra: bf1e34c07b208222 upload(797) done() b/w a(10.111.222.1:46080->100.72.229.245:443) => b([2a00:23c8:311a:b501:7593:2325:8525:99b2]:42938<-[2606:2800:21f:cb07:6820:80da:af6b:8b2c]:443)

It happens because Rethink doesn't "have" or has "lost" v4 addresses for example.com. Looking...

ignoramous commented 3 months ago

Applying strict routes (to dialers) will break in cases like #1543 where the underlying network has v6 but the overlay network (WireGuard) only has v4.