[Android 13] VPN connection is not working with 4G data network #1523
Replies: 2 comments 4 replies
-
|
You are probably on a NAT64 network. Try disabling the persist-tun option from the VPN itself. It disables lookup of DNS and that seems to be needed in your case. |
Beta Was this translation helpful? Give feedback.
-
|
This might also be because of an Android 13 bug too. See: |
Beta Was this translation helpful? Give feedback.
-
|
According to that disucssion it seems to be NAT464 related, so disable persist-tun in my app and use a hostname instead of IP to connect the server and it should work. |
Beta Was this translation helpful? Give feedback.
-
|
In my limited opinion, being far from an expert on Android, the issue with Android 13 seems to be only with blocking the clatd daemon's network access when "Block connections"/lockdown mode is enabled. Without clatd (and the tun interfaces it sets up), there are no IPv4 routes or interfaces for apps that are attempting to connect with IPv4 addresses. I can use ics-openvpn as-is with a commercial VPN by specifying hostname because DNS64 returns a "fake" AAAA DNS record for upstream A records; the NAT64 prefix + IPv4 address is returned to the app as if it resolves to an IPv6 address, and the VPN connection succeeds. No need to specify persist-tun, though clatd is still in a broken state with no IPv4 connectivity without a DNS64 intercept. However, in my case, I have a private VPN that is only accessible over IPv4 and no hostname. Network Unreachable is returned if I use the IPv4 address, but it does work if I create a duplicate OpenVPN profile with the destination host being the NAT64 prefix + IPv4 address. Unfortunately there's not much to go on as a I scour the internet for people with similar issues, so sadly my own observations are the best I can offer. |
Beta Was this translation helpful? Give feedback.
-
|
So basically clatd is a hack to workaround broken apps that do not properly use DNS and NAT64. And that breaks. So you are probably better off creating just some hostname for your static IP, so that works for you without having to resort to the clatd hack. Not that iOS does not have this hack and will even reject apps from the app store if they do not work in a NAT64 environment rather than relying on something like clatd. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks again for the great work here, being able to take back some control of how my mobile traffic is handled is really important. Here for a 👍 and a question. TL;DR:
Background: I encountered this same problem after moving to Android 13 (Google official builds) on several devices. Currently the "fleet" consists of a Pixel 6A and a Pixel 7, both on the latest OEM OS builds. Symptoms were that after leaving WiFi range, I would have no connectivity from the mobiles. VPN had, for years, been working without issues with Android always-on and "block without VPN" enabled, and with pesistent tun enabled, using static IPv4 server addresses. Servers are my own. Mobile network is Google Fi (T-Mobile US MVNO) and from what I can tell (in a sideways manner using a data-only G Fi SIM and tethering so I can observe traffic easily) they are running an access network that relies on NAT64/DNS64 for IPv4 connectivity. I finally managed to mostly fix this by adding DNS A records for my VPN servers. While at it, I also ensured that they're reachable over IPv6 and added AAAA records too. This has fixed the "UDPv4 network unreachable" problem I was seeing in the client. To fully restore app functionality when on mobile data though it also required setting I have now also unchecked I'm asking this because in a scenario where I e.g. move from mobile only (IPv6 plus NAT64/DNS64) state, where the client has connected to the IPv6 server address, into a WiFi with IPv4 only, it would presumably require a fresh DNS lookup to maintain the connection. I'd like to confirm that it is in fact true that having one hostname per server, each with a pair of A and AAAA records, would mean that I'd still get a new DNS lookup and a float, instead of a ping-restart and reconnection that would take much longer to restore connectivity. Versus, say, a single hostname with a bag of A and AAAA records that span all the servers across both stacks, which would roll the dice every time. I currently use the one hostname per server in the client config, each of which should be getting a pair of A and AAAA records from DNS. Based on client logs, seems to be "preferring" the IPv6 addresses, both on Google Fi's network and on my dual-stack WLAN, so far. But I haven't done any serious testing yet. (edited for clarity/terminology). |
Beta Was this translation helpful? Give feedback.
-
General information
Android 13
Kernel version: 4.14.276-g8ae7b4ca8564-ab8715030
Build number: TP1A.220624.014
Google
Google Pixel 4a
F-Droid built and signed version 0.7.39
Description of the issue
Hello,
Since upgrade to Android 13 on my Google Nexus 4a, OpenVPN is not able to connect to 4G data network anymore.
Connections with WIFI are still working as usual.
Of course if I disable "Block connection without VPN" and "Permanent VPN" in Android VPN settings, my 4G data network is working without VPN.
Log (if applicable)
Logs of a working Wifi connection, then 2 minutes later switch off wifi to try to switch to 4G data network:
Configuration file
Thank you for your work!
Beta Was this translation helpful? Give feedback.
All reactions