search

AdguardTeam / AdguardForAndroid

Open bug tracker for Android version of AdGuard.
https://adguard.com/
1.36k stars 90 forks source link

Wi-Fi calling issue with AdGuard (and other VPNs) and its solution #2550

Closed ameshkov closed 5 years ago

ameshkov commented 5 years ago

To the moment, we'd had multiple complaints on Wi-Fi calling being incompatible with AdGuard. In this issue, I'll explain what's going on and how we can solve this.

How it works

Any Wi-Fi network is considered untrusted (compared to the provider's own network) so in order to transfer voice data, your phone must establish a secure encrypted tunnel with the provider's server called ePDG [1].

image

The tunnel is encrypted and uses IPSec so basically this is another VPN. ePDG server discovery is simple: all ePDG server names look like epdg.epc.mnc%MNC%.mcc%MCC%.pub.3gppnetwork.org where %MNC% is your provider's Mobile Network Code, and %MCC% is its Mobile Country Code. You can find these values of your provider here: http://www.mcc-mnc.com/. Both values are padded with zeros to the length of 3.

Why is there a problem with AdGuard (or other VPNs)

Android cannot establish a tunnel with the ePDG when this connection is routed through a VPN. Presumably, it happens due to a bug in the Android's IPSec client, and we should file a bug report about it. It shows connections as 0.0.0.0->ePDG IP instead of something like 192.168.11.x->ePDG IP (the socket is not bound to a proper local interface), and that's why it can send data to the tunnel, but it cannot receive it.

Example of a temporary solution (manual)

You can figure what your ePDG server is and exclude it from the VPN. In this case, the tunnel connection won't be routed through a VPN, and you won't run into this issue.

In some cases (see #2432) it is not enough to exclude ePDG, and it's necessary to exclude the IPv6 range as well. I don't know why yet.

For instance, for Vodafone UK, MCC is 234, and MNC is either 15 or 91. Knowing this we can figure what IP addresses do ePDG servers have.

We should simply lookup these two domains: epdg.epc.mnc015.mcc234.pub.3gppnetwork.org and epdg.epc.mnc091.mcc234.pub.3gppnetwork.org. Only the first one of them resolves, and the IP addresses are 88.82.11.221 and 88.82.11.208.

Once you have these addresses, do the following:

  1. Open AdGuard -> Go to Settings -> Advanced -> Low-level
  2. Find pref.ipv4.routes.excluded and tap on it
  3. Add two new lines there: 
    88.82.11.221/32
88.82.11.208/32
  4. ePDG tunnel should now be okay, and Wi-Fi calling should work

AdGuard solution

This section is for devs.

We are yet to figure how to discover the current operator's ePDG server automatically. Once we know it, we can simply add it's IP addresses to the excluded routes. The problem here is that I don't want us to ask for Telephony permission, that'd be too much for such a simple thing.

Another possible solution would be to exclude the UID that establishes the ePDG tunnel. It seems that it's done by /system/bin/eris (uid=1000).

Android bug

I've filed a bug report to Android devs: https://issuetracker.google.com/issues/124415915

Lurchus commented 5 years ago

Thanks ameshkov,

Working with zzebrum I also added the exclusion:

88.82.11.0/24

And that was the first time I was able to get WiFi calling working on Vodafone UK without having to flick in to flight mode and disable AG for a moment to get connected.

Should I leave that in the exceptions along with the 2 other you mention to add:

88.82.11.221/32 88.82.11.208/32

Thanks.

ameshkov commented 5 years ago

@Lurchus 88.82.11.0/24 would do, it is a little bit wider and includes all IP addresses between 88.82.11.0 and 88.82.11.255. This is okay, though.

sahlouls commented 5 years ago

Hi @ameshkov,

Help wanted.

I wish to enable voWIFI on my Oneplus device (voLTE already working). The issue is that this handset is not supported by SFR (France carrier).

From differnt issues, the IPv4 and IPv6 addresses for SFR VPN servers are publicly known:

But how to configure my device in the 1st place to add/configure VPN access and enable voWIFI (later I will whiteliste then in the Android app)

Many thanks,

carlosalbornoz commented 2 years ago

Was having trouble getting Wi-Fi calling to work while using AdGuard but I stumbled upon this post on how to fix it. (Smart Philippines) Sharing the folllowing ePDG IPs used by our carriers here in the Philippines for Wi-Fi calling activation:

// epdg.epc.mnc003.mcc515.pub.3gppnetwork.org // SMART Philippines Wi-Fi calling 203.87.172.0/24 121.54.55.0/24

// weconnect.globe.com.ph (Globe uses a different domain for their ePDG servers. Similiar to how AT&T does it) // Globe Philippines Wi-Fi calling 110.54.220.0/24

// epdg.epc.mnc066.mcc515.pub.3gppnetwork.org // DITO Telecommunity Wi-Fi calling 131.226.72.0/24 131.226.73.0/24

EDIT 9/24/24: Changed IP address values for Globe and DITO Telecommunity

Birraque commented 2 years ago

I`m having issues getting Wi-Fi calling to work while using AdGuard v3.6.8 on Xiaomi Poco F3:

// epdg.epc.mnc010.mcc724.pub.3gppnetwork.org // Vivo Brazil Wi-Fi calling 152.255.14.0 152.255.2.16

Then I would like to know what is correct parameter (mask) to be add after IPs addresses: /24 ??? Thanks in advance for your inputs.

Regards,

ameshkov commented 2 years ago

@Birraque

Yeah, /24 should be okay.

Please let me know if this helped.

Birraque commented 2 years ago

@Birraque

Yeah, /24 should be okay.

Please let me know if this helped.

Thank you for your inputs. I added in the pref.ipv4.orutes.excluded list:

//Vivo Brazil Wi-Fi calling 152.255.14.0/20 152.255.2.16/20

VoLTE/Wi-Fi seem to be working fine know but I 'll let you know if have any issue. Best regards,

Birraque commented 2 years ago

@Birraque

Yeah, /24 should be okay.

Please let me know if this helped.

Hi @ameshkov I'm currently using pref.ipv4.routes.excluded for epdg.epc.mnc010.mcc724.pub.3gppnetwork.org with:

// Vivo Brazil Wi-Fi calling 152.255.14.0/20 152.255.2.16/20

But after a few days I realize that VoWiFi doesn't register when move from 4G network to WiFi if AdGuard filtering method (local VPN) is enabled. When VoWiFi is connected with local VPN the VoWiFi connection drops randomly or when answering an incoming call. Do you have any inputs? How to handle it? Thanks in advance, regards.

krystofkrticka commented 2 years ago

Here are ePDGs of all major carriers in Czech Republic

I double checked every IP using icann lookup tool

Vodafone CZ ePDG DNS name: epdg.epc.mnc003.mcc230.pub.3gppnetwork.org IP: 31.30.69.152/32 IP: 31.30.69.153/32

O2 CZ ePDG DNS name: epdg.epc.mnc002.mcc230.pub.3gppnetwork.org IP: 160.218.3.4/32 IP: 160.218.3.2/32

T-Mobile CZ ePDG DNS name: epdg.epc.mnc001.mcc230.pub.3gppnetwork.org IP: 62.141.11.56/32 IP: 62.141.11.59/32

ameshkov commented 2 years ago

@Birraque

Do you have any inputs? How to handle it?

Tbh, no idea what could be causing this since the routes are excluded regardless of whether you're connected to 4G or Wi-Fi :(

Birraque commented 2 years ago

@Birraque

Do you have any inputs? How to handle it?

Tbh, no idea what could be causing this since the routes are excluded regardless of whether you're connected to 4G or Wi-Fi :(

Maybe some IPv6 range configuration or exclusion is needed but I don't know how to handle it. Do you have any input about this issue?

ameshkov commented 2 years ago

@Birraque the only more or less normal way to troubleshoot this is to capture the system bug report right after reproducing the issue. Here's the instruction.

The log inside the bug report will contain lines from the process named eris and you'll see where it tries to connect.

Here's an example of what we're looking for:


02-12 16:36:42.781 10731 10764 I eris    : 11[DMN] [eris_interface] handle_request - type = MSG_TYPE_CONNECT
02-12 16:36:42.782 10731 10764 I eris    : 11[DMN] operator_code : MTS
02-12 16:36:42.793 10731 10764 I eris    : 11[LIB] created TUN device: epdg1
02-12 16:36:42.797 10731 10764 I eris    : 11[DMN] Host Address 192.168.11.182
02-12 16:36:42.805 10731 10764 I eris    : 11[IKE] initiating IKE_SA IMS[35] to 213.87.143.150
02-12 16:36:42.822 10731 10764 I eris    : 11[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
02-12 16:36:42.822 10731 10764 I eris    : 11[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:42.823 16936 16357 D Native.TCPIP.UDPMNGR: [VpnService-main] [LWIP id=10] new UDP connection request [172.18.11.218:59288](https://www.google.com/url?q=http://172.18.11.218:59288&sa=D&source=buganizer&usg=AOvVaw3Xyy4Uo6I3SGtJde0aOoD5) -> [213.87.143.150:500](https://www.google.com/url?q=http://213.87.143.150:500&sa=D&source=buganizer&usg=AOvVaw0psWTx9anF7rt-P-xLDkHo)
02-12 16:36:43.823 10731 10763 I eris    : 12[IKE] retransmit 1 of request with message ID 0
02-12 16:36:43.823 10731 10763 I eris    : 12[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:45.823 10731 10765 I eris    : 13[IKE] retransmit 2 of request with message ID 0
02-12 16:36:45.823 10731 10765 I eris    : 13[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:49.824 10731 10766 I eris    : 16[IKE] retransmit 3 of request with message ID 0
02-12 16:36:49.824 10731 10766 I eris    : 16[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:52.824 10731 10770 I eris    : 09[IKE] giving up after 3 retransmits
02-12 16:36:52.824 10731 10770 I eris    : 09[DMN] update {event 5, error 4, ike_error 0} for conn[2]
02-12 16:36:52.824 10731 10770 I eris    : 09[DMN] [eris_interface] send_status
02-12 16:36:52.826 10731 10770 I eris    : 09[IKE] establishing IKE_SA failed, peer not responding
02-12 16:36:52.826 10731 10766 I eris    : 16[IKE] unable to terminate IKE_SA: ID 35 not found
02-12 16:36:53.098 10731 10763 I eris    : 12[DMN] [eris_interface] handle_request - type = MSG_TYPE_CONNECT
`` `
Birraque commented 2 years ago

@Birraque the only more or less normal way to troubleshoot this is to capture the system bug report right after reproducing the issue. Here's the instruction.

The log inside the bug report will contain lines from the process named eris and you'll see where it tries to connect.

Here's an example of what we're looking for:

02-12 16:36:42.781 10731 10764 I eris    : 11[DMN] [eris_interface] handle_request - type = MSG_TYPE_CONNECT
02-12 16:36:42.782 10731 10764 I eris    : 11[DMN] operator_code : MTS
02-12 16:36:42.793 10731 10764 I eris    : 11[LIB] created TUN device: epdg1
02-12 16:36:42.797 10731 10764 I eris    : 11[DMN] Host Address 192.168.11.182
02-12 16:36:42.805 10731 10764 I eris    : 11[IKE] initiating IKE_SA IMS[35] to 213.87.143.150
02-12 16:36:42.822 10731 10764 I eris    : 11[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
02-12 16:36:42.822 10731 10764 I eris    : 11[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:42.823 16936 16357 D Native.TCPIP.UDPMNGR: [VpnService-main] [LWIP id=10] new UDP connection request [172.18.11.218:59288](https://www.google.com/url?q=http://172.18.11.218:59288&sa=D&source=buganizer&usg=AOvVaw3Xyy4Uo6I3SGtJde0aOoD5) -> [213.87.143.150:500](https://www.google.com/url?q=http://213.87.143.150:500&sa=D&source=buganizer&usg=AOvVaw0psWTx9anF7rt-P-xLDkHo)
02-12 16:36:43.823 10731 10763 I eris    : 12[IKE] retransmit 1 of request with message ID 0
02-12 16:36:43.823 10731 10763 I eris    : 12[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:45.823 10731 10765 I eris    : 13[IKE] retransmit 2 of request with message ID 0
02-12 16:36:45.823 10731 10765 I eris    : 13[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:49.824 10731 10766 I eris    : 16[IKE] retransmit 3 of request with message ID 0
02-12 16:36:49.824 10731 10766 I eris    : 16[NET] sending packet: from 0.0.0.0[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:36:52.824 10731 10770 I eris    : 09[IKE] giving up after 3 retransmits
02-12 16:36:52.824 10731 10770 I eris    : 09[DMN] update {event 5, error 4, ike_error 0} for conn[2]
02-12 16:36:52.824 10731 10770 I eris    : 09[DMN] [eris_interface] send_status
02-12 16:36:52.826 10731 10770 I eris    : 09[IKE] establishing IKE_SA failed, peer not responding
02-12 16:36:52.826 10731 10766 I eris    : 16[IKE] unable to terminate IKE_SA: ID 35 not found
02-12 16:36:53.098 10731 10763 I eris    : 12[DMN] [eris_interface] handle_request - type = MSG_TYPE_CONNECT
`` `

I`ll do that. Thanks!

ollrich commented 2 years ago

Hi there,

I got a new phone and I'm using it with the same Adguard settings and SIM as my old one, which totally worked fine regarding WiFi Calling.

With my new phone WiFi Calling doesn't work anymore when Adguard is activated. I figured out the ePDG for Vodafone Germany, at least the one which are in the Adguard logs: epdg.epc.mnc002.mcc262.pub.3gppnetwork.org

Corresponding IPs are 139.7.117.168 and 139.7.117.169

So, I set them in pref.ipv4.routes.excluded and WiFi-Calling was on for 10 seconds than back off again.

Did I miss something or what else can I do?

Thanks a lot and best regards, Oliver

Birraque commented 2 years ago

@Birraque the only more or less normal way to troubleshoot this is to capture the system bug report right after reproducing the issue. Here's the instruction.

The log inside the bug report will contain lines from the process named eris and you'll see where it tries to connect.

Here's an example of what we're looking for:

Hi @ameshkov

My carrier (Vivo Brazil) is currently on going rollout to 5G (DSS/NSA/SA) network and this has caused instabilities in services. Anyway I did the correct subnet calc and Add the bellow address/mask to the AdGurad's pref.ipv4.routes.excluded

// Vivo Brazil Wi-Fi calling 152.255.14.0/24 152.255.2.16/28

Subnet Calc (Screenshots) for epdg.epc.mnc010.mcc724.pub.3gppnetwork.org

152.255.14.0/24

152.255.2.16/28

AdGuard is running smoothly now with VoLTE/VoWiFi and I can confirm that both values are correct and could be included in the future AdGuard builds. Thank you very much for all your support, regards

elween07 commented 2 years ago

I use Chunghwa Telecom LDM and excluded 221.120.20.1/24 221.120.23.1/24

it NOT work for me, so now I turn off adguard in com.qualcomm.qti.cne at app management then look good. Unless you are adamant that all traffic has to go through adguard I think this is a solution too

karlays commented 1 year ago

Hello, for Movistar Spain there are problems: MCC is 214, and MNC is 07