Filtering doesn't work with 4G and IPv6

[the4anoni]

Issue Details

Like in topic.
See: AdguardTeam/AdguardFilters#60690 (comment)

• AdGuard version:
  • v3.5 nightly 7
• Filtering mode:
  • Local VPN
• Device:
  • Samsung Galaxy S10
• Operating system and version:
  • Android Q
• Root access:
  • No

Expected Behavior

Filtering should work.

Actual Behavior

It doesn't

[TheHasagi]

@the4anoni

Sorry for the late reply, but can you try with the latest Nightly version?

[the4anoni]

@the4anoni

Sorry for the late reply, but can you try with the latest Nightly version?

I tried latest nightly and it didn't fixed problem. On IPv4 everything works ok.

[TheHasagi]

@the4anoni

Hello, we've released a fresh Beta version, can you check with it?

[the4anoni]

@the4anoni

Hello, we've released a fresh Beta version, can you check with it?

Seems it's ok now.

[the4anoni]

Edit: Cosmetic filtering still has problems like empty space left by ads. No such problems on IPv4.

[TheHasagi]

@the4anoni

Please, check with the latest nightly version, if the issue is still relevant, provide the settings and debug logs to [email protected]

[the4anoni]

@the4anoni

Please, check with the latest nightly version, if the issue is still relevant, provide the settings and debug logs to [email protected]

Logs sent.

[TheHasagi]

@the4anoni

Did not received the logs yet, can you re-send them again with the subject "issue/3527"?

[the4anoni]

@the4anoni

Did not received the logs yet, can you re-send them again with the subject "issue/3527"?

Ok, I've resend logs.

[TheHasagi]

@the4anoni Got it, thanks.

[tox1c90]

I am experiencing a similar issue which first had me believe that the problem is related to the filters because of several missed ads: AdguardTeam/AdguardFilters#63551

However, it turned out that it's related to the way I'm connected to the internet when Adguard is enabled. My cellular connection is native IPv6 (IPv4 realized only via carrier grade NAT), while the WiFis which I am using are IPv6+IPv4 (at home) or IPv4 only (at work).

I made the following observations, each one starting from the state where Adguard is disabled:

1. Connected only to cellular connection (4G, IPV6): Enable Adguard -> content filtering is not working correctly. However, simple DNS filtering is applied (adguard.com/en/test.html shows Adguard is not running). Rough blocking in browser works, because many ads are caught by DNS filtering, but only with ugly white spaces as leftovers.
2. Connected to one of the WiFis (IPv4 only, or IPv6+IPv4 both native): Enable Adguard -> both DNS as well as usual content blocking is working fine (adguard test page shows Adguars is running), filtering works as usual
3. In the final state of case 2. when filtering is working properly, disable WiFi connection -> internet connection is now via cellular connection only, but Adguard is still working properly! The issue appears again, if I now disable and re-enable Adguard. Then the outcome is as described in case 1.

So, for me the issue is clearly related to the type of internet connection in the moment where Adguard protection is started. If it's cellular -> only DNS filtering works. If it's WiFi -> everything works. If I switch to cellular from WiFi, I have to avoid restarting Adguard protection, because then it stops working properly.

In all cases btw., the browser reports "Adguard Personal CA" as certificate when HTTPS is used. However, this has no implication for if content is actually filtered or not.

Information about device etc.: Google Pixel 3a, Android 11 (just updated yesterday when it became available), Adguard 3.5, local VPN, no root.
I initially thought it might be related to Android 11, but having seen the OP is running Android 10 makes me wondering if that's really the case.

[tox1c90]

I found a workaround that is mitigating the problem at least for my mobile carrier (Telekom in Germany). Very recently, they changed the default APN to "internet.v6.telekom" which is establishing a native IPv6 only connection and only assigns a public IPv6 adress to individual devices. IPv4 is then realized by carrier grade NAT (i.e. thousands of users share the same public v4 adress). However, in case of compatibility problems they allow you to change the APN back to "internet.telekom" which restores the old dual stack behaivor, i.e. you will get both a public IPv6 and IPv4 adress.

By changing to the old APN, Adguard immediately starts to work via cellular data. I have no clue though why Adguard cares about the type of internet connection depending on whether you get a real public IPv4 adress or not.
In my opinion, that should not make any difference in case of a local VPN, right? So I would still consider this a bug.

Do this issue still get some attention, because it seems like the bot unassigned the developers (sry, I don't know too much about how Github issue tracker works)? :D
Just in case it got lost, I try to explicitly mention you @TheHasagi

[antek821]

Hi. I noticed on two Android devices (both running on Android 10) that Adguard doesn't work when using a cellular connection with 4G and IPv6, same as with @the4anoni and @tox1c90.
There has been no reply on this topic for months. @TheHasagi did you manage to find out something about this problem during this time?

[the4anoni]

I wanted to ask for this too, I've reported issue almost half year ago.

[antek821]

As there is still no response from @TheHasagi , I'm mention other people from Adguard Team: @Chinaski1 @zzebrum @ameshkov @sfionov

[ameshkov]

Thanks for mentioning me.

Am I right that both of you're running AG in the standard VPN mode?

[the4anoni]

Thanks for mentioning me.

Am I right that both of you're running AG in the standard VPN mode?

Yes, at least me.

[tox1c90]

Yes, me too!

[antek821]

Thanks for mentioning me.

Am I right that both of you're running AG in the standard VPN mode?

Yes, on both devices.

[ameshkov]

Got it, we're looking into it, thank you!

[sfionov]

There are two problems:

1. AdGuard now routes only IPv6 global unicast (2000::/3)
2. local.adguard.org is IPv4 for simpler redirection.

So, in IPv6-only networks with well known NAT64 prefix (64:ff9b::/96), any IPv4 site will not be filtered, including local.adguard.org
In IPv6-only networks with custom NAT64 prefix, AdGuard doesn't prevent connection to local.adguard.org, and it works in the same way as injections.adguard.org.

So, this needs to be resolved on both AdGuard and CoreLibs sides. On AdGuard side, 64:ff9b::/96 should be in filtered prefixes list.
On CoreLibs side, we should hijack NAT64'ed local.adguard.org connections.

[sfionov]

Seems that there's nothing to do with this in CL, it is enough to add route.

[ameshkov]

@sfionov what exactly should we have in pref.ipv6.routes.excluded to keep 2000::/3 excluded, but 64:ff9b::/96 included? Do we have a simple tool that helps to calculate a CIDRs list like that?

[sfionov]

@ameshkov

2000::/3 is only included route now, not excluded.

Excluded routes should stay empty.
Included routes (that are hardcoded now) should be changed from alone 2000::/3 to 2000::/3 and 64:ff9b::/96 since 64:ff9b::/96 belongs to different prefix - ::/3 (IETF reserved), not 2000::/3 (IPv6 global unicast).

Do we have a simple tool that helps to calculate a CIDRs list like that?

We doesn't have a simple tool that do prefixes exclusion (only Java and C++ classes) but they are not needed in this case.

[ameshkov]

Included routes (that are hardcoded now)

Ah, my bad, missed that. So it seems a code change is necessary to solve this one.

@artemiv4nov when do we plan to push the next nightly update?

[artemiv4nov]

Well, the task completed, and the next nightly version will be available this week.

[tox1c90]

Thank you! I can confirm it's working now with the latest nightly.

[the4anoni]

For me latest nightly fixed issue too. Thanks @ameshkov @artemiv4nov