Wireguard 0.55n has issues connecting if IP of Wireguard server has changed

[Braintoe]

I was a bit surprised to not find this here - the closest one might be #1538 . The older issue #1367 was something different.

Therefore let me add this here:

My Wireguard server is my local router (a Fritzbox) which connects to the Internet via a DynDNS service since the IP of my internet access usually changes every day.

ReThinkDNS has an issue with finding the Wireguard server then, which results in a stalled Wireguard connection (no data comes in) and makes "Always-on" unusable. Toggling either "total blockage" or the Wireguard connection itself usually fixes the issue - until the IP of the Wireguard server changes again.
Until now, I failed to find a task on the phone which, when excluded from the Wireguard connection, would solve the issue. (Judging from AfWall+, I would have expected I need to exclude ReThinkDNS and/or the system DNS service from Wireguard, but that does not change anything)
As far as you can tell from the DNS protocol it seems ReThinkDNS does a query of the WG server but is happy if it finds it in its cache and does not care further. "DNS Amplifier" is off, "Never proxy DNS" either since that option does too much since it excludes all DNS entries from cache and Wireguard proxy. DynDNS URL of WG server is added as trusted domain.

Edit: corrected error description (see below for details): ReThink does get the new IP of the Wireguard server from the DNS, but it ignores the change and does not connect to Wireguard. That also explains why e

Expected behaviour would be that ReThinkDNS will

1. do a DNS query of the defined Wireguard server if it detects a lack of answers from that server and if that server is a URL that you can query and ignore the DNS cache in that case
2. and then try to reconnect to that server if the IP has changed..

Here is how to reproduce:
a) phone is running and the WG server changes its ip address:

• set up / activate your wireguard tunnel, defining the endpoint as a URL (I use simple mode with total blockage)
• change the IP address (but not the DNS name) of the WG server
• Wireguard within ReThinkDNS will stall, seemingly no automatic attempt to reconnect will be made (I guess however ReThink keeps answering its own DNS query from its cache only for some reason). You need to manually disable Wireguard and restart it to get it running again.

b) WG server IP changes while phone is off:

• set up / activate your wireguard tunnel, defining the endpoint as a URL(I use simple mode with total blockage)
• set up your phone to request SIM card PIN after boot (should block mobile network access until phone is booted)
• shutdown phone
• change the IP address (but not the DNS name) of the WG server
• start phone, let it rest about a minute to let it finsh booting
• enter SIM card PIN and confirm. Phone will connect to mobile network now.
• Wireguard within ReThinkDNS will stall, seemingly no automatic attempt to reconnect will be made. You need to disable Wireguard and restart it to get it running again. If you are lucky, toggling the "total blockage" button off for 1...2 seconds and on again will do the job as well.

[ignoramous]

Thanks. I can see why this may happen.

Usually though, we expect dynamic DNS records changes to coincide with network changes (need not be the case, but usually is). If so, the endpoint domain is re-queried for IP.

We'll try to re-query after TTL expires.

[Braintoe]

@ignoramous if you expect DNS record changes to coincide with network changes, that is indeed a possible explanation. But unless I overlook something, this means it will basically never work if your Wireguard server depends on a DynDNS service:

• if your phone is connected via your local WiFi area and the router that connects the server gets a different IP, the network stays the same, but the IP changes
• if your phone is connected via another Wifi area, the same happens because the phone is still in the same Wifi network
• if your phone is connected to the mobile network, the same happens again because the phone is still in the same mobile network
• even if your phone is off and reconnects to the same network (Wifi or mobile) as before, RethinkDNS seems to treat this as "still the same network" and ignores the fact that the network was gone in between, hence the same applies there as well.
• if you put your phone into flight mode and then turn flight mode off again (which is usually the recommended solution to flush the DNS cache on a mobile phone), ReThinkDNS will prevent that since the phone reconnects to the same network.

Would it be possible to add some setting which turns this behaviour off and / or accept "no network" (flight mode) and any phone boot as a network change, even if if the network ID the phone reconnects to is the same?

[ignoramous]

if your phone is off and reconnects to the same network (Wifi or mobile) as before, RethinkDNS seems to treat this as "still the same network"

Not really. Whether or not 2 things are the "same network" actually depends on how Android reports it to Rethink. Rethink cannot and does not treat different networks as "same network" unless Android tells it to.

(which is usually the recommended solution to flush the DNS cache on a mobile phone)

Strange. Recommended by whom? There are a couple of ways to flush DNS caches (reddit / mirror).

possible to add some setting which turns this behaviour off and / or accept "no network" (flight mode) and any phone boot as a network change

It is possible to add new settings but since only power users use dyndns, I am reluctant to add it, especially since the major complaint by users of the app is the existing settings introducing complexity.

---

Today, Rethink will reconnect/re-establish WireGuard tunnel if you tap on the "Refresh" icon at the top right-hand corner of the Configure -> Proxy screen. This refresh should also trigger a re-evaluation of Peer (endpoint) names, if any.

Other than that, I think re-querying once the DNS answer time-to-live expires should be enough?

[Braintoe]

Strange. Recommended by whom? There are a couple of ways to flush DNS caches (reddit / mirror).

Chip.de and Adguard for example, just as the first two results a quick search for "clear dns cache android" gave out:
https://praxistipps.chip.de/android-dns-cache-loeschen-so-gehts_172797
https://adguard-dns.io/kb/public-dns/solving-problems/how-to-flush-dns-cache/

But there are numerous others as well.

It is possible to add new settings but since only power users use dyndns, I am reluctant to add it, especially since the major complaint by users of the app is the existing settings introducing complexity.

Yes, that is a valid objection. Such a setting would need to be in some "extended settings" are which ReThink does not have today.

Today, Rethink will reconnect/re-establish WireGuard tunnel if you tap on the "Refresh" icon at the top right-hand corner of the Configure -> Proxy screen. This refresh should also trigger a re-evaluation of Peer (endpoint) names, if any.

Okay, I admit I have never noticed that one. I would have expected such an icon to be in the Proxy connection screen since "configuration" means for me "settings only" - while all connections are activated and deactivated in this screen:

I just tried that one, it does not help - see below.

Other than that, I think re-querying once the DNS answer time-to-live expires should be enough?

I fear I need to rephrase the issue, thanks for forcing me to take another, deeper look.

This is what I get:

DNS (done from my computer to get the TTL values):
From the Adguard DNS server which I told Rethink to use I get from dig:

;; ANSWER SECTION:
aetherfunk.ddnss.de.    30      IN      A       93.195.226.5

If I use the DNS server 8.8.4.4 Rethink obviously uses on its own after phone boot at times, I get

;; ANSWER SECTION:
aetherfunk.ddnss.de.    112     IN      A       93.195.226.5

which means the entry should be re-queried after less than two minutes at max. ReThink seems to only pay limited care however - after I reconnected, it took about six minutes until the DNS query entry showed the current IP (unclear how old the cached entry was though, so the real TTL ReThink uses might be longer) - and interestingly enough, the DNS protocol shows all entries - both old and new - as "resolved by Cache". This means, I misjudged that and you cannot trust the "resolved by Cache" notice since the new IP must to have been resolved from somewhere else than the cache unless you did some real magic :-)

But that is not not the only problem I noticed (and this is what I never noticed before):
even if ReThink has learned of the changed IP, the Wireguard connection still does not react. Instead, it stays stuck in "waiting" - "failing" - "waiting" - "failing". This state did not change for the last 45min. Using the button you suggested did not help at all.

In the meantime, the DNS entry gets polled every 2 minutes. This tells me it is actually not the DNS that fails but the Wireguard reconnection itself.

In this state, I can

• toggle the "total blockage" button within the Wireguard connection off/on which for some reason helps somtimes, but in other cases only resets the Upload/Download counter in the Wireguard Proxy view
• toggle the Wireguard connection itself off/on which then usually resolves the issue but lets all waiting connections briefly get out of the VPN tunnel.

[Braintoe]

Okay, after keeping an eye on this for some more days I updated the error description in the first post. The problem is that Rethink does not seem to update its Wireguard module after a DNS change of the Wireguard server. If you happen to have some new version that might solve this, I will be happy to test it :-)