IPv6 broken v0.5.5n 240824

[haraldrudell]

Hi,

What Rethink should be doing is support paired IPv6 and IPv4 WireGuard VPNs, always try IPv6 first, if failure IPv4 similarly supporting tunneled IPv4/IPv6 traffic per WireGuard configuration

Current Issues latest v0.5.5n 240824:

1. There is a 10 s slowness during browsing first access, typically this is caused by routing issues FIX: select “Bypass app from all proxies” for any IPv6 app. This is the get-around to fast again. The get-around also makes IPv6 work at all

2. Rethink confuses tunneled address family and transport address family, which is common among developer new to IPv6 where there are many combinations to keep sorted. This must be very clear at every step and settings name. When wrapping inside SOCKS5, even more combinations

3. The Proxy box on Home tab displays “Failing” despite WireGuard being fine. On use, it seems to go to “Active”

4. Frequently a toaster appears “IPC error -22: failed to set endpoint [x::y]:51820: wg: bind:…” This typically is caused by providing an improper structure to the operating system. It may be why things are slow. My case Android 12. Errno 22 is EINVAL invalid something, typically a value

5. There is a Rethink — Configure — Network — Choose IP version. This setting should be deleted. IPv6 is automatic. The strategy is ALWAYS IPv6 first, if it fails IPv4. LTE that is a late design is always IPv6. Wi-Fi that is managed by antiquated engineers is often IPv4 only. it is ms to figure it out

6. Wireguard not good for dual-family transport. Either Rethink needs to support multiple WireGuard and use the first one working, or WireGuard Proxies may be paired of which one is active, or a WireGuard Proxy may have two peers, one IPv4 one IPv6 and only one used at a time. This is feature outside of WireGuard

7. If IPv6 not automatic and requires settings, it is not done right. Always IPv6 first, then maybe IPv4

My configurations work fine in the WireGuard app

Thank you

[ignoramous]

There is a 10 s slowness during browsing first access

10s sounds high, but WireGuard requires a reconnect if KeepAlive is not set, but it shouldn't take 10s, though reconnects may take time.

Rethink confuses tunneled address family and transport address family ... This must be very clear at every step and settings name. When wrapping inside SOCKS5, even more combinations

Sorry, I don't get. What does this mean?

The Proxy box on Home tab displays “Failing” despite WireGuard being fine. On use, it seems to go to “Active”

That's okay if no KeepAlive is set, and as long as WireGuard re-connects.

Frequently a toaster appears “IPC error -22: failed to set endpoint [x::y]:51820: wg: bind:…

Do you see this happen only when running WireGuard in Advanced mode? We fixed one such issue #1545 (not yet released). Unsure if that fixes for what you're seeing too.

Either Rethink needs to support multiple WireGuard and use the first one working

Rethink does this when there's multiple Always-on WireGuard configuration active #1477

If IPv6 not automatic and requires settings

It is automatic. You should be able to see if both IPv4 and IPv6 are active or not by tapping on the downward arrow next to the START / STOP button.

[haraldrudell]

2. address families:

There are basic routing problems. Without ridding of those, other mysterious symptoms will occur

transport packets is the packets the WireGuard client sends to the WireGuard server — for a given connection configuration, all are of either IPv4 or IPv6 family, WireGuard does not support anything else specified by [Peer] Endpoint

tunneled packets are those Android apps send into the tunnel — depending on tunnel configuration those are IPv4 only, IPv6 only or dual-stack: a mix of IPv4 and IPv6 packets specified by [Peer] AllowedIPs and [Interface] Address

then DNS can respond on IPv4 or IPv6 or both, and those responses contain IPv4 or IPv6 or both

What I see is that with — WireGuard IPv4 transport for a dual-stack tunnel Rethink — Configure: Network — Choose IP version: Auto (experimental) for an app: IPv4 is No route to host IPv6 works I think this is BUG, IPv4 should work

When set to IPv4 (default), for an app: IPv4 works IPv6 is No Route to Host

There are clearly bugs here and lots of address-family combinations to test

At every turn, it must be known what kind of packet is this and what address families are possible

I do not think it makes sense to ever block an address family that is working, like IPv6 — there was a period when lazy people considered IPv6 optional — after aws charges for IPv4 in 2023, there is lots of IPv6-only — there is no technical need to support IPv4 anymore, only legacy reasons

This is the problem to solve first. transport and tunnel address family working as expected It is possible that all other symptoms after that disappear

— 1. 10 s slowness:

The 10 s talk above by me can be buggy android or buggy android apps encountering what they have never seen before Once the basic routing works per address family, it is possible there are no other issues

—3. FAIL

If the WireGuard can be snoozing but not failed, I think there should be a third state that may be “unknown” or “idle” If it says FAIL it should be because there is an actual failure as in something in the configuration or connectivity needs to be fixed It is also interesting if the state is NO CONNECTIVITY, which is a special kind of fail as in please turn off Airplane mode That can also be there is no connectivity or Android thinks there is no connectivity

As of Rethink 0.5.5n it is difficult to determine if WireGuard is operational Rethink — Home: Proxy — Once the numbers for the active proxy becomes large, they do not change very often What we would like to know is: a. how long since the last received packet? like a good useful packet, or possibly also any packet b. how long since the last SUCCESSFUL handshake? failing handshakes are not interesting c. is a handshake overdue?

basically, we want to know if the thing is considered to be working fine right now or is is about to fail (eg. connectivity was recently lost) or is it failed (eg. there is no connectivity) or did it never work (eg. no such server)

BUG: if the screen is narrow, the values are written on top of each other

— 7. Automatic 5. IP version

What I mean here is there should not be any settings in regards to address family — It can be determine from network-interface address-family assignments, routes and attempted configuration what the resulting connectivity should be —before a failure can be returned, it is possible that both IPv4 and IPv6 needs to be attempted separately — if IPv6 looks to work, try that first — In Go, you create a thread for each possibility then pick the one that succeeds first and cancel others. This requires cancel to work well, and thread-safety. Creating a virtual thread takes time, too

Termux can be used like: nping --tcp-connect --count 1 --dest-port 443 8.8.8.8 && nping -6 --tcp-connect --count 1 --dest-port 443 2001:4860:4860::8888

curl -4 ip.me; curl -6 ip.me

Note that mobile networks typically are IPv6 only with trickery to support IPv4

[haraldrudell]

— 4 IPC 22

I think IPC 22 occurs when you have run WireGuard IPv6 transport, that does not work at all in v0.5.5n, then switching back tp IPv4 BUG: WireGuard IPv6 transport does not appear to work BUG: When switching from IPv6 to IPv4 IPC22 toaster appears

[haraldrudell]

Another issue is that when Rethink blocks IPv6 for no particular reason, IPv6 traffic from particular app cannot be bypassed using “Bypass app from all proxies” such traffic is rejected

Instead one must do: Settings — Network & internet — VPN — Rethink: cogwheel — Block connections without VPN: Off then use the “Exclude” FIREWALL RULES FOR THIS APP

I think the fix here is that: “Bypass app from all proxies” should work for IPv6 traffic when upstream has IPv6

[haraldrudell]

Another bug seems to be that Rethink — Configure: Network — Choose IP version BUG: never supports both IPv4 and IPv6 simultaneously for tunneled packets BUG: seems to control both transport and tunneled packets this setting should not exist at all

I think when it is operating in IPv6 with IPv6 WireGuard, that breaks DNS or something so that curl -6 ip.me can never complete. This is probably where the 10 s delays come from

When you are in this troubled state, it seems STOP START is necessary to get back to good graces, ie. some sticky setting prevents WireGuard from connecting and Rethink decides DNS should come from WireGuard and nothing works after that

—

The way to go here is to allow IPv4 and IPv6 always with IPv6 preferred and let whatever not present fail after that deal with any slowness this may cause after that please jurassic users with legacy blocking and preference options for the weird things they might want to do call those settings legacy this or legacy that so it is clear why they exist