[Feature request] Multihop for mobile apps

[codenyte]

I have checked if others have suggested this already

• I have checked this issue tracker to see if others have reported similar issues.

Feature description

WireGuard Multihop for the Android and iOS app

Alternative solutions

Using the WireGuard app with a multihop configuration. Not a great solution though. It would be much better if this was possible in the official mobile app.

Type of feature

• Better privacy/anonymity
• Better at circumventing censorship
• Easier to use
• Other

Operating System

• Android
• iOS
• Windows
• macOS
• Linux

[albin-mullvad]

Thanks for this feature request! We'll discuss this internally.

[codenyte]

Thanks for reviewing this! I've been waiting for this feature for years.

[Lolagatorade]

Needs much more than just this. The app is severely lacking on iOS compared to the other operating systems.

Shaddowsocks no way to use. No way to properly configure and use bridges ect. lack of documentation for iOS. Just have to pray and hope the bridge option has enough alternate configurations to circumvent any censorship when you arrive to the destination

[agnosticlines]

Would love to see this land in iOS! :-)

[drpoutine]

Feature is now on iOS build 2024.5 (2) on testflight

[codenyte]

Awesome, is this also planned for Android?

[drpoutine]

Awesome, is this also planned for Android?

its slightly not ready for prime time. on iOS ive noticed the tunnel drops the connection quite a bit. especially if youre double hopping between 2 servers in the same country.

[codenyte]

What makes this so difficult on mobile? It works just fine on desktop? And is this behavior also observable when just using the WireGuard profile with a multi-hop configuration?

[albin-mullvad]

Awesome, is this also planned for Android?

The feature is currently quite high up in our backlog, but we don't have a plan for when to work on it yet.

[issuant]

but we don't have a plan for when to work on it yet.

This is very sad to hear.

[drpoutine]

update on this feature with the iOS Mullvad app, works great for it being a beta feature.
Using version 2024.8-beta4 exclusively on wireguard tunnels only and Quantum-resistant tunnel enabled.

there is a weird bug that might be related to some sort of networking bug where the tunnel interface isn'y properly restarted which results in a connecting loop.

Workaround is to disconnect and force crash the app then attempt to establish the connection again.
(or just wait a minute then try again? hit or miss on this one)

I've attached the full log:
mullvad-2024.8b8-multihop.log
on a successful multihop established tunnel

System information:
id: C11196FC-D007-4A5E-9593-39833E249737
mullvad-product-version: 2024.8-beta4
os: iOS 18.0.1

====================
[REDACTED CONTAINER PATH]/net.mullvad.MullvadVPN_09-10-2024T23:01:18.log
====================
MullvadVPN version 2024.8-beta4
[09/10/2024 @ 23:01:18][AppDelegate][debug] Registered app refresh task.
[09/10/2024 @ 23:01:18][AppDelegate][debug] Registered address cache update task.
[09/10/2024 @ 23:01:18][AppDelegate][debug] Registered private key rotation task.
[09/10/2024 @ 23:01:19][RelayCacheTracker][debug] Start periodic relay updates.
[09/10/2024 @ 23:01:19][AddressCache.Tracker][debug] Start periodic address cache updates.
[09/10/2024 @ 23:01:19][AddressCache.Tracker][debug] Schedule address cache update at 10/10/2024 @ 20:54:18.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-relays.1 Send request to /app/v1/relays via [REDACTED]:443 using url-session.
[09/10/2024 @ 23:01:19][TunnelStore][debug] Loaded persistent tunnel: DBDD4243-FC5D-4C83-9895-521356B17969 with status: connected.
[09/10/2024 @ 23:01:19][TunnelManager][debug] Refresh tunnel status for new tunnel.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-access-token.3 Send request to /auth/v1/token via [REDACTED]:443 using url-session.
[09/10/2024 @ 23:01:19][ApplicationRouter][debug] Presenting .main.
[09/10/2024 @ 23:01:19][AppDelegate][debug] Finished initialization.
[09/10/2024 @ 23:01:19][StorePaymentManager][debug] Load transaction log.
[09/10/2024 @ 23:01:19][StorePaymentManager][debug] Start payment queue monitoring
[09/10/2024 @ 23:01:19][TunnelManager][info] Status: connected (PQ) daita: false to us-nyc-wg-403 via us-chi-wg-305, network reachable.
[09/10/2024 @ 23:01:19][TunnelManager][debug] Start polling tunnel status every 5s.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-relays.1 Response: 200.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-access-token.3 Response: 200.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-my-account.2 Send request to /accounts/v1/accounts/me via [REDACTED]:443 using url-session.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-my-account.2 Response: 200.
[09/10/2024 @ 23:01:19][REST.NetworkOperation][debug] name=get-device.4 Send request to /accounts/v1/devices/{id} via [REDACTED]:443 using url-session.
[09/10/2024 @ 23:01:20][REST.NetworkOperation][debug] name=get-device.4 Response: 200.
[09/10/2024 @ 23:01:22][ApplicationRouter][debug] Presenting .settings(nil).
[09/10/2024 @ 23:01:22][SettingsNavigationCoordinator][debug] Navigate from none -> root
[09/10/2024 @ 23:01:22][REST.NetworkOperation][debug] name=get-device.5 Send request to /accounts/v1/devices/{id} via [REDACTED]:443 using url-session.
[09/10/2024 @ 23:01:22][REST.NetworkOperation][debug] name=get-device.5 Response: 200.
[09/10/2024 @ 23:01:23][SettingsNavigationCoordinator][debug] Navigate from root -> problemReport

otherwise, running automations for toggling Cellular Data the tunnel will restarts the tunnel as expected by connecting to a new server.

[issuant]

@albin-mullvad any progress on this feature for Android? I must say I find it strange iOS managed to get prioritized for such a feature when that OS is a complete mess.

[Lolagatorade]

@albin-mullvad any progress on this feature for Android? I must say I find it strange iOS managed to get prioritized for such a feature when that OS is a complete mess.

Say what you will man but your beautiful android system had a severe bug.
https://www.bleepingcomputer.com/news/security/android-bug-leaks-dns-queries-even-when-vpn-kill-switch-is-enabled/

On top of that developing for android is a nightmare, considering how many different systems there are and versions, coustom hardware and software layered ontop of the already extensive fragmentation. Ect.

See what you will, but it is pretty logical to focus on a system that will give you very nice consistent results and afterwards you're gonna focus on the system that's more fragmented if your goal is to solidify an idea such as multi hop or obfuscation; Then do it on system that is more stable. Once you see that it's possible then you can go ahead and apply what you have learned onto a more difficult and fragmented system.

That's exactly why developing for Linux is so annoying because there are so many distributions. It's easier to either develop for Mac or for windows because the Linux first philosophy is just so complicated at times and the workarounds generally involve sandboxes, etc. Same applies for phones ect.

So give the developer some time and mullvad will get to a point where it's available on every system with full features

[issuant]

What does that tirade have to do with what I said and who said anything about Android being beautiful?

[albin-mullvad]

Thanks for the continued interest of adding Multihop to the Android app! I'm glad to let you know we recently started the implementation.

[issuant]

Good to hear that.

[drpoutine]

Thanks for the continued interest of adding Multihop to the Android app! I'm glad to let you know we recently started the implementation.

WOOOO can't wait for this to work smooth on Graphene <3

[ghost]

I would love to see that too!

[drpoutine]

update on this feature with the iOS Mullvad app, works great for it being a beta feature. Using version 2024.8-beta4 exclusively on wireguard tunnels only and Quantum-resistant tunnel enabled.

there is a weird bug that might be related to some sort of networking bug where the tunnel interface isn'y properly restarted which results in a connecting loop.

Workaround is to disconnect and force crash the app then attempt to establish the connection again. (or just wait a minute then try again? hit or miss on this one)

so it seems like #7231 is directly related to the problem i was having. setting quantum resistant tunnel to Automatic/Off seems to resolve the issue I was having for a long time on multihop where the tunnel establishment would hand.

I also noticed the same problem if i have quantum resistant tunnel enabled with DAITA on alongside multihop

workaround seems to be just disabling quantum resistant tunnel or setting it to automatic, which makes the tunnel establish as expected.

otherwise, running automations for toggling Cellular Data the tunnel will restarts the tunnel as expected by connecting to a new server.

this solution was always a hit or miss in retrospect, did not think to check if other settings would be affecting the behavior of tunnel establishment at the time.

PS:

Add multihop which allows the routing of traffic through an entry and exit server, making it harder to trace.

saw this in the added today but i guess this will be implemented in beta 2 for android. cant wait to test this out soon

[ghost]

Any Updates on this topic?

[Pururun]

Any Updates on this topic?

We have merged the PR:
#7036

Multihop will not be in the next release (2024.9) which is currently in beta, but unless something unexpectedly happen it should be in the next release after that.

[ghost]

Any Updates on this topic?

We have merged the PR: #7036

Thank you for telling.

Multihop will not be in the next release (2024.9) which is currently in beta, but unless something unexpectedly happen it should be in the next release after that.

Oh nice! Thank you for telling!

[codenyte]

Multihop will not be in the next release (2024.9) which is currently in beta, but unless something unexpectedly happen it should be in the next release after that.

@Pururun Only iOS, or Android as well?

[Pururun]

Multihop will not be in the next release (2024.9) which is currently in beta, but unless something unexpectedly happen it should be in the next release after that.

@Pururun Only iOS, or Android as well?

Android will, unless something unexpectly happen, have multihop in the next release after 2024.9 (so NOT 2024.9) which will be either 2024.10 or 2025.1.

iOS should have multihop since 2024.6

[codenyte]

Thanks for the reply, that's amazing!