Android OpenVPN on IPv6 entry layer MTU problems

[ss11 20]

While playing at the office today discovered something interesting:

On Android (13), when connected to a Wi-Fi network that offers both IPv4 (NAT) and IPv6 (native via DHCPv6), when connecting to the AirVPN OpenVPN server via entry layer IPv6 there is a MTU problem.

By default AirVPN ships OpenVPN config files with MTU 1500 for both IPv4 and IPv6 entry layers.

Example 1: connected from Android via Wi-Fi, native IPv6, to AirVPN OpenVPN server via entry layer IPv6, go to test page test-ipv6.com:

Example 2: From the same device, connected to the same AirVPN OpenVPN server, from the same Wi-Fi network, except via IPv4 entry layer, the problem does not exist:



Example 3: If you change the MTU of the OpenVPN config file with the IPv6 entry layer from MTU 1500 to MTU 1280, it works as expected again:

Other considerations:

- The behavior DOES NOT APPLY to Desktops (Windows or Linux), I don't know why, it's just for Android.
- I have not tried with WireGuard, but if someone can try with WireGuard from Android via IPv6 entry layer from Wi-Fi, I am eager to see the results, as WireGuard uses a smaller default MTU, and I saw AirVPN WireGuard configs do not change that, but it's just an assumption we need to check;

Goal:
- If all above confirms, in our Client Area -> Config Generator we might want to default  to MTU 1280 when entry layer IPv6 or entry layer Dual-Stack (not yet implemented but who knows) AND device is Android. And we might look into other OS'es (RPI, router, Mac) if this problem exists;
- Eddie to be adjusted accordingly of course - did not test if Eddie has this problem;

Other comments appreciated.



 

[OpenSourcerer 1441]

What's your client, version and config?

Oh, and cannot reproduce with:

13:50 F-Droid built and signed version 0.7.46 running on Fairphone FP4 (FP4), Android 13 (TQ2A.230505.002) API 33, ABI arm64-v8a, (Fairphone/FP4eea/FP4:12/SKQ1.220201.001/SP28:user/release-keys)

Connected to Mesarthim, DE. Native IPv6 available:

# ip -o a
[…]
20: wlan0    inet 192.168.110.42/24 brd 192.168.110.255 scope global wlan0\       valid_lft forever preferred_lft forever
20: wlan0    inet6 2003:[…]:f8ad:f44e:2705:b763/64 scope global temporary dynamic \       valid_lft 6868sec preferred_lft 1468sec
20: wlan0    inet6 2003:[…]:18ec:5b79:a9d6:b8e6/64 scope global dynamic mngtmpaddr stable-privacy \       valid_lft 6868sec preferred_lft 1468sec
20: wlan0    inet6 fe80::637d:8ffd:5c4a:de3/64 scope link stable-privacy \       valid_lft forever preferred_lft forever

.

[ss11 20]

@OpenSourcerer sorry for the late reply, was traveling

Client: OpenVPN for Android 0.7.43
OpenVPN version: icsopenvpn/v0.7.43-0-gd861a123
OpenSSL version: OpenSSL 3.0.7 1 Nov 2022
---
OS: Android 13
Kernel: 5.15.41-android13-8-25800099
Android Security Patch level: May 1, 2023
Vendor: Samsung / OneUI version 5.1
-----
Config: Downloaded from Client Area -> Config Generator -> Advanced
Client OS: Android
Advanced options: Mobile (prefer CHACHA)
Entry layer: IPv6
OpenVPN first recomennded variant, connect via UDP

That's all, the rest of config params are generated automatically by AirVPN. If you need anything specific from the OpenVPN config I can post here, let me know.

[OpenSourcerer 1441]

On 6/20/2023 at 3:24 PM, ss11 said:

Client: OpenVPN for Android 0.7.43

Let's update this first and try again. Current is 0.7.46.

[ss11 20]

For me (Google Play Store / vendor: Samsung) the latest is 0.7.43 where exactly did you see 0.7.46 ?
Also, I don't think it's related to the version, it's something only related to MTU and Android, but again I have no problems in retrying with any version, except for me 0.7.43 is the current and latest one.

[OpenSourcerer 1441]

My log. Also: https://github.com/schwabe/ics-openvpn/releases
Well, I cannot reproduce your problem. Have you tried different wireless networks, plus GSM?
Are you certain your router is not doing some MTU magic with IPv6 packets?

[ss11 20]

Yes, I can see as well that the latest release is as you said, somehow Google Play did not verify it yet or did not push the update downstream.

Anyway, you are right the fist rational step is to try from different networks, the problem is none of my GSM carriers support IPv6 at all, and I did not had the chance to try from a different wi-fi network that provides native IPv6, but will do this in the next days.

I have discovered that the router where this happens uses PPPoE/PPPoEv6 and uses a MTU (assigned by the ISP that cannot be changed) of 1492 - could that be it, since the OpenVPN MTU is 1500 and tries to push via an upstream gate of 1492? As I said, the problem goes away if I set tun-mtu 1280 on OpenVPN. Also, curious is that 1492 ISP MTU is also for IPv4, and the problem does not occur if I connect via entry layer IPv4. Also, more non-android devices (Desktop computers) are connected to the same router, and if I connect them to AirVPN via entry layer IPv6 the problem does not occur, and I leave the OpenVPN tun-mtu to 1500 as it is shipped by default. Isn't this curious?

[OpenSourcerer 1441]

1 hour ago, ss11 said:

I have discovered that the router where this happens uses PPPoE/PPPoEv6 and uses a MTU (assigned by the ISP that cannot be changed) of 1492 - could that be it, since the OpenVPN MTU is 1500 and tries to push via an upstream gate of 1492?

You would've had the same problem with IPv4 if that setting were a problem.

Do you have access to a shell on your Android device? You can enable one in Developer settings starting with Android 11, I think. In there you could try a series of pings with varying packet sizes to nail down what your optimal MTU is. Ask away if you have questions about any of that.

[ss11 20]

Right. Somehow it only affects when the entry layer is IPv6 and protocol is OpenVPN with default tun-mtu 1500 as shipped by AirVPN.

I have just tried now with Wireguard on same server, same device, same wi-fi network, and the problem is not happening. Same with OpenVPN entry layer IPv4 works fine. it's just OpenVPN with entry layer IPv6 and tun-mtu set to 1500 that causes it, if I manually switch mtu to 1280 when connecting via entry layer IPv6 (OpenVPN) problem is as well fixed. Too bad my carrier (mobile sim provider) does not offer IPv6 to try, I can only try from wi-fi.