AdGuard blocking Wi-Fi calling when using default settings.

[Ketawa757]

My very first bug report, hopefully I don't do anything incorrect.

• AdGuard version: v3.5.1
• Filtering mode: Local VPN
• Device: Google Pixel 4 XL
• Operating system and version: Android 10.0.0
• Root access: No

Expected Behavior

I have Google Fi with Wi-Fi calling enabled. My device should use Wi-Fi calling when it offers a better connection than mobile data. It is possible to force Wi-Fi calling by turning on airplane mode, then turning on Wi-Fi. This leaves mobile data off and will force the phone to use Wi-Fi calling, which I confirmed works correctly when AdGuard protection is not enabled.

Actual Behavior

When AdGuard is enabled, my device will not use Wi-Fi calling. It's difficult to provide evidence of this outside of airplane mode, because the phone still completes calls, it just never uses Wi-Fi calling. When airplane mode is enabled, it will not dial. Instead, it provides a message of "Turn off airplane mode to make a call." I can't figure out what is causing the block by scanning the Filtering Log.

Screenshots

Screenshot: successful Wi-Fi call with AdGuard disabled

Screenshot: failed Wi-Fi call with AdGuard enabled

[TheHasagi]

@Ketawa757

To troubleshoot this issue, we need to get additional logs.

Here's what we need you to do:

1. Collect the debug log as it's explained here.
2. Remember the exact time when the issue was reproduced, we will need it to find the corresponding records in the log file.
3. Additionally, capture the system bug report after reproducing the issue. Here's the instruction.
4. Send both files to [email protected]. Mention the Github issue number and the exact time when the issue was reproduced.

[Ketawa757]

Logs sent as requested, please let me know if there are any issues accessing them.

[TheHasagi]

@Ketawa757

Hello, did not receive the logs. Can you send them again and mention it with subject issues/3627?

[Ketawa757]

Resent.

[admitrevskiy]

@Ketawa757 Hi! Could you provide me additional info please? Go to your phone Settings -> Network & Internet -> Mobile Network -> Advanced -> Access Point Names -> Google Fi (?)

I'm interested in the MCC and MNC values

[Ketawa757]

Hello, I am on Google Fi using eSIM, and there is no way to view APN settings. Here is the menu when I go to Settings -> Network & Internet -> Mobile Network.

Screenshot: "Mobile Network" menu with "Advanced" expanded

[Ketawa757]

Searching settings for Access Point Names takes me to that menu. There isn't anywhere to drill down for MCC and MNC values, and they don't show up anywhere else I can find in settings.

[admitrevskiy]

There is no drop-down Advanced menu? :(

[Ketawa757]

There is; I expanded it in the screenshot. It only reveals the 3 menu choices under "Calling": Wi-Fi calling: on/off selector switch, it's on System select (Change the CDMA roaming mode): "Home only" or "Automatic Erase SIM: self-explanatory

[Ketawa757]

I think I had some luck messing with dialer codes. On a Pixel phone, Google Fi can use any of T-Mobile, Sprint, or UScellular. The phone gives me this message when switching to each network: "Switching to MCC/MNC: ______"

T-Mobile: 310260 Sprint: 310120 UScellular: 311580

I have coverage with all 3 at home where I captured my logs, but I was probably on T-Mobile, maybe Sprint.

[admitrevskiy]

That's something! Let's try to exclude providers subnets from filtering, it may help

Go to AdGuard Settings -> Advanced -> Low level settings -> pref.ipv4.routes.excluded

And add these subnets to the list:

198.230.0.0/16 
68.24.0.0/13
 208.54.0.0/17 
208.54.128.0/19

[Ketawa757]

Done, still having the same issue.

[admitrevskiy]

Let's try other ways to figure out what's going wrong:

1. Try to reproduce this issue with AdGuard 3.4: https://github.com/AdguardTeam/AdguardForAndroid/releases/download/v3.4-release/adguard-3.4-release.apk

2. If issue is not reproducable go to Settings -> Advanced -> Low-Level Settings -> pref.filtered.ports And change it to 80,443,3128,3130,3143,4443,5443,6443,7275,7443,8000:27010,27012:35880,35882:49151

3. If issue still exist please try to contact Google Fi support and ask them which port is used for WiFi calling

[EntropySmoke]

Carrier-based WiFi calling uses its own 3GPP IPSec ePDG VPN tunnels on Android phones and bypasses VPN apps. I think it is due to IPTables chain rules that you can only edit on rooted phones after each restart or via Magisk module and/or via AFWall+ custom script. Normally you need IPSec ports 500 and 4500 unfiltered to allow IPSec to work correctly, but each carrier is different.

Carrier-based WiFi calling doesn't even show up in AdGuard logs when carrier-based WiFi calls happen. I know it bypasses AdGuard local VPN (or any other VPN client), but a local DNS server, such as AdGuard Home, shows 3GPP domain resolution attempts (with MCC/MNC in domain names) from devices that want to use carrier-based WiFi calling.

Google Voice WiFi calling (without a carrier on a phone without a SIM card) also bypasses VPN connections (local or not) and bypasses AdGuard's "Block WebRTC" feature. Google Voice forces a direct STUN connection with Google over UDP ports 19302-19305. You can only find that out if you use "TCPDump -i any -vv" logs.

Google Voice is the only app that shows up labeled "root" in AdGuard filter log. I think it gets low-level root access and does what it wants on Android phones.

[sfionov]

@EntropySmoke On most devices, ePDG tunnel can't choose outgoing interface address for validating, when "system" app and ePDG routes are not excluded (You may see it in logcat - when adguard is on, epdg tunnel rejects every packet because it is not for "0.0.0.0" 😬).

But resolving ePDG routes by MNC/MCC automatically requires TELEPHONY permission, which AdGuard doesn't have. That's why AdGuard excludes "system". I assume that something else changed here in Android 10, and excluding "system" doesn't help anymore.

[EntropySmoke]

@EntropySmoke On most devices, ePDG tunnel can't choose outgoing interface address for validating, when "system" app and ePDG routes are not excluded (You may see it in logcat - when adguard is on, epdg tunnel rejects every packet because it is not for "0.0.0.0" 😬).

But resolving ePDG routes by MNC/MCC automatically requires TELEPHONY permission, which AdGuard doesn't have. That's why AdGuard excludes "system". I assume that something else changed here in Android 10, and excluding "system" doesn't help anymore.

That is beyond my level of beginner understanding... for now. I don't know what kind of a protocol AdGuard Local VPN uses, but WiFi carrier calling ePDG tunnels on phones always use IPSec protocol. It is a standard. I don't think you can encapsulate IPSec within an OpenVPN or a WireGuard tunnel. I know AdGuard can resolve ePDG domain with whichever DNS you specify, but it doesn't filter IPSec packets.

It could be an issue with OP's specific carrier. Maybe it uses a non-default port that AdGuard filters by default. On my Android 11 phones, I specify 1:65535 (all ports!) in AdGuard Low Level settings and it doesn't prevent WiFi calling from working. It resolves ePDG tunnel domain with DoH on my Android 11 devices and WiFi carrier calls work. Then again, we have very little control over what mobile phones do, especially if they are not rooted, connected to Google Mobile Services + connected to mobile carriers...

[ameshkov]

@EntropySmoke a little bit more info on this bug here: https://issuetracker.google.com/issues/124415915

[ameshkov]

@sfionov check out how it was resolved btw:

The recommended solution (and the one adopted on Pixel devices) is to create the IPsec SA with the XFRM_OUTPUT_MARK (or XFRM_SET_MARK) netlink attribute set to a value that will bypass the VPN. Since this bug was reported on a Samsung, the Android team cannot fix it. Samsung needs to make this change (or another change) in their code.

[Jayman007]

I am on Google Fi with a Samsung G20+ 5G on Android 11. I have this exact same issue. It has taken me nearly a month to figure out it was Ad Guard that was causing the issue. Now that I can place wifi calls with adguard disabled and as soon as I enable it then I get the same error I used to get about not being able to place calls in airplane mode.

I was going to open a new bug ticket until I find this one. Has anything been solved here? It sounds like the issue is something that Samsung needs to change? How best to bring it to their attention with the exact fix so they can work to resolve it?

On a side note, I see that it was resolved for this user on a different carrier with some exclusions. https://github.com/AdguardTeam/AdguardForAndroid/issues/1796

Is this something we can hope to get working on Google Fi?

[Jayman007]

@Ketawa757 Hi! Could you provide me additional info please? Go to your phone Settings -> Network & Internet -> Mobile Network -> Advanced -> Access Point Names -> Google Fi (?)

I'm interested in the MCC and MNC values

I am on the same carrier and have this same issue.

The MCC is 310 The MNC is 260

[ameshkov]

Well, the bug itself is Samsung-specific so if they haven't fixed it, I doubt anything can help.

We could try excluding wifi calling IP addresses from the VPN tunnel, but it hadn't helped the TC as I recall (yet it should've - maybe another Samsung bug).

In order to figure out what IPs to exclude, please do the following:

1. Enable debug-level logging - settings - advanced - logging level - record everything
2. Reproduce the issue
3. Export logs via settings - advanced
4. Inspect the logs and find connections to ports 500 and 4500 (or just send the logs to [email protected] - mention this issue in the email)

[Jayman007]

I don't believe this is a samsung specific issue. The OP for this bug is on a Pixel handset. Even in the Google bug tracker it's stated that this is reproducible on any Android handset. If this fix is required on the device manufacturer level then where do we report this to Samsung so that they can work on a resolution?

(logs removed by @ameshkov)

I have attached some logs to look over. The time I was testing was 1633-1636. When I looked my previous logs over I didn't find anything on either port 500 or 4500. As mentioned above, Google Fi might be doing it a different way (using STUN?).

I'm watching the logs on my home firewall and can't seem to identify the traffic being used for the wifi calling. Nothing on ports 500 or 4500. However I am seeing traffic using STUN (destination port UDP:19302 used everytime) to ip 172.253.117.127. I tried excluding this IP in Ad Guard with no luck.

[ameshkov]

It seems (from their reply) that they've fixed it since then on Pixel devices, but other manufacturers should also do this.

identify the traffic being used for the wifi calling. Nothing on ports 500 or 4500

That's strange. Let's try logcat then. Here's what needs to be done:

1. Reproduce the issue
2. Capture bug report: https://developer.android.com/studio/debug/bug-report
3. In the bug report archive there'll be a huge txt file that will contain the logcat log
4. Look for records from eris, they'll look like this:

02-12 16:38:25.547 10731 10772 I eris    : 08[IKE] initiating IKE_SA IMS[38] to 213.87.143.150
02-12 16:38:25.582 10731 10772 I eris    : 08[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:38:25.582 10731 10772 I eris    : 08[NET] sending packet: from 192.168.11.182[59288] to 213.87.143.150[500] (464 bytes)
02-12 16:38:25.626 10731 10770 I eris    : 09[NET] received packet: from 213.87.143.150[500] to 192.168.11.182[59288] (424 bytes)
02-12 16:38:25.626 10731 10770 I eris    : 09[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
02-12 16:38:25.633 10731 10770 I eris    : 09[IKE] local host is behind NAT, sending keep alives
02-12 16:38:25.636 10731 10770 I eris    : 09[IKE] establishing CHILD_SA IMS{9}
02-12 16:38:25.636 10731 10770 I eris    : 09[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR6 DNS6 PCSCF6) N(ESP_TFC_PAD_N) SA TSi TSr N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
02-12 16:38:25.636 10731 10770 I eris    : 09[NET] sending packet: from 192.168.11.182[51469] to 213.87.143.150[4500] (352 bytes)
02-12 16:38:25.767 10731 10763 I eris    : 12[NET] received packet: from 213.87.143.150[4500] to 192.168.11.182[51469] (160 bytes)
02-12 16:38:25.768 10731 10763 I eris    : 12[ENC] parsed IKE_AUTH response 1 [ N((41101)) IDr EAP/REQ/AKA ]
02-12 16:38:25.768 10731 10763 I eris    : 12[IKE] server requested EAP_AKA authentication (id 0x02)
02-12 16:38:25.770 10731 10763 I eris    : 12[DMN] simID : 0
02-12 16:38:25.912 10731 10763 I eris    : 12[IKE] allow mutual EAP-only authentication
02-12 16:38:25.913 10731 10763 I eris    : 12[IKE] server requested DEVICE_IDENTITY
02-12 16:38:25.913 10731 10763 I eris    : 12[ENC] generating IKE_AUTH request 2 [ EAP/RES/AKA ]
02-12 16:38:25.913 10731 10763 I eris    : 12[NET] sending packet: from 192.168.11.182[51469] to 213.87.143.150[4500] (112 bytes)
02-12 16:38:25.970 10731 10764 I eris    : 11[NET] received packet: from 213.87.143.150[4500] to 192.168.11.182[51469] (80 bytes)

[Jayman007]

I did a bug capture on my device but I am not finding any entries for eris in the large txt file. I am taking another one now and will email a link for you guys (it's over 25MB, too big for gmail).

I certainly hope we can figure out what to exempt from AdGuard to get this working as I really hate the idea of no longer using AdGuard just to have wifi calling working.

[ameshkov]

Got it, please send it to [email protected] then. Please mention this issue in the email body.

[Jayman007]

I sent the file to [email protected] a few days ago. Please confirm you received it. It was over the 25MB limit that gmail allows so I included both a dropbox link as well as a google drive link.

[ameshkov]

Hm, I don't see it. Could you please also forward it to [email protected]?

[ameshkov]

@Jayman007 got your bug report, thank you!

[Jayman007]

Any luck on figuring out Google Fi's ePDG domains/IPs? It drives me crazy that I must keep adguard disabled so that wifi calling works. I love adguard and want to be able to use it again ASAP.

As a temp fix, is it possible to restrict Ad Guard to my cell connection? Keep the wifi interface from ever using Ad Guard. I think that might allow me to keep adguard enabled but the connection to the ePDG over wifi will work.

No idea if this will even work but I'd like to test. At least I could cut ads out of my cellular surfing.

[ameshkov]

Nothing helpful in the log unfortunately.

But I've found some interesting info on Google Fi: https://wifidevan.wordpress.com/2020/09/14/how-to-setup-your-network-for-wi-fi-calling/

I tried to find ePDG of Google Fi, who allows the phones select either T-Mobile and Sprint based on the signal strength at the location. After doing multiple packet captures, I was scratching my head unable to find any IPsec packets. My phone still shows the call as a Wi-Fi call, but it doesn’t establish an IPsec tunnel unlike traditional mobile operators. Google takes an interesting approach to establish phone calls. Instead of IPsec tunnel to the ePDG, it initiates all calls (wi-Fi or LTE) as google hangout/talk audio calls. It then sends the packets to the ePDG of T-Mobile or Sprint.

Here's a plan that I suggest:

1. Try completely disabling filtering for IPv4/IPv6. For that check pref.vpn.ipv4.bypass and pref.vpn.ipv6.bypass in the low-level settings. When these enabled, your whole network will be excluded from filtering as if AdGuard was not working at all. The purpose is to see if excluding routes can potentially help with this problem.
2. If it starts working, then I suggest disabling filtering one by one for all apps in the Apps Management settings (starting with "Android OS" and hangouts). This way we'll find which one is responsible for making calls.

As a temp fix, is it possible to restrict Ad Guard to my cell connection? Keep the wifi interface from ever using Ad Guard. I think that might allow me to keep adguard enabled but the connection to the ePDG over wifi will work.

Well, you could use Tasker to automate it like that: https://kb.adguard.com/en/android/solving-problems/tasker