New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv4 mapped addresses bypass VPN #1026

Closed
theseanl opened this Issue Jan 17, 2017 · 24 comments

Comments

Projects
None yet
5 participants
@theseanl

theseanl commented Jan 17, 2017

Edit[ameshkov]: cause for this issue: #1026 (comment)


There are many users reporting this. A user have to enable some low-level ipv6 settings (pref.vpn.ipv6.disable, pref.vpn.ipv6.bypass, pref.proxy.block.ipv6) to have all ads blocked.

A user have sent logs. The user is using a mobile carrier 'SK Telecom'. The user tested an app com.dcinside.app while collecting logs below.


Local HTTP proxy mode - ads were not blocked
adguard3.log.txt

Local HTTP proxy mode & pref.proxy.block.ipv6 enabled - The internet connection is completely broken. When the user turns off the Adguard protection, the internet connection remains broken, and the user have to disable and re-enable cellular data to connect to the internet.
adguard4.log.txt

Local VPN mode & DNS request filtering enabled - almost all ads are blocked except some.
adguard5.log.txt

Local VPN mode & DNS request filtering enabled & pref.vpn.ipv6.disable enabled -
All ads are blocked.
adguard6.log.txt

Local VPN mode & DNS request filtering enabled & pref.vpn.ipv6.bypass enabled - Ad blocking result is the same as the case of local VPN mode & DNS request filtering enabled, i.e. enabling pref.vpn.ipv6.bypass does not make any difference.
adguard7.log.txt

@ameshkov ameshkov added this to the 2.9 milestone Jan 17, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Jan 17, 2017

Member

Here are some thoughts about it.

  1. In adguard5.log I see DNS requests to dcinside.com subdomains, but I don't see actual connections and requests further.
  2. On the contrary, in adguard6.log I see both DNS requests and actual connections.

The only thing I have in mind is that dcinside.com are resolved to some local IPv6 addresses, hence not covered by AG routing.

Here is what we should do to check if I am right:

  1. Extend DNS requests logging. We should also log DNS response content.
  2. Change default routing for IPv6 network and cover local addresses as well.
Member

ameshkov commented Jan 17, 2017

Here are some thoughts about it.

  1. In adguard5.log I see DNS requests to dcinside.com subdomains, but I don't see actual connections and requests further.
  2. On the contrary, in adguard6.log I see both DNS requests and actual connections.

The only thing I have in mind is that dcinside.com are resolved to some local IPv6 addresses, hence not covered by AG routing.

Here is what we should do to check if I am right:

  1. Extend DNS requests logging. We should also log DNS response content.
  2. Change default routing for IPv6 network and cover local addresses as well.
@theseanl

This comment has been minimized.

Show comment
Hide comment
@theseanl

theseanl Jan 20, 2017

Let me know when a new build comes out!

theseanl commented Jan 20, 2017

Let me know when a new build comes out!

@ameshkov ameshkov self-assigned this Feb 7, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Feb 16, 2017

Member

Necessary changes will be available in the beta version.

Most of all I am interested in this case: Local VPN mode & DNS request filtering enabled

Member

ameshkov commented Feb 16, 2017

Necessary changes will be available in the beta version.

Most of all I am interested in this case: Local VPN mode & DNS request filtering enabled

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Mar 10, 2017

Member

@seanl-adg is there any update on this issue with the new beta version release?

Member

ameshkov commented Mar 10, 2017

@seanl-adg is there any update on this issue with the new beta version release?

@ameshkov ameshkov modified the milestones: 2.10, 2.9 Mar 15, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Mar 15, 2017

Member

Reassigned to v2.10

Member

ameshkov commented Mar 15, 2017

Reassigned to v2.10

@theseanl

This comment has been minimized.

Show comment
Hide comment
@theseanl

theseanl May 10, 2017

The same user have sent another set of logs.

Configurations were the same, the tested app is com.dcinside.app and the mobile carrier's name is SK Telecom.


Local HTTP proxy mode - ads were not blocked, there is no sign of blocking in the filtering log too.
1.txt

Local HTTP proxy mode & pref.proxy.block.ipv6 enabled - The internet connection is completely broken. When the user turns off the Adguard protection, the internet connection remains broken, and the user have to disable and re-enable cellular data to connect to the internet.
2.txt

Local VPN mode & DNS request filtering enabled - Google ads are blocked. An ad which should be blocked by ||dcinside.com/api/_ad_search_link.php^ wasn't blocked. Some other ads weren't blocked.
3.txt
screenshot3

Local VPN mode & DNS request filtering enabled & pref.vpn.ipv6.disable enabled -
All ads are blocked.
4.txt
screenshot4

theseanl commented May 10, 2017

The same user have sent another set of logs.

Configurations were the same, the tested app is com.dcinside.app and the mobile carrier's name is SK Telecom.


Local HTTP proxy mode - ads were not blocked, there is no sign of blocking in the filtering log too.
1.txt

Local HTTP proxy mode & pref.proxy.block.ipv6 enabled - The internet connection is completely broken. When the user turns off the Adguard protection, the internet connection remains broken, and the user have to disable and re-enable cellular data to connect to the internet.
2.txt

Local VPN mode & DNS request filtering enabled - Google ads are blocked. An ad which should be blocked by ||dcinside.com/api/_ad_search_link.php^ wasn't blocked. Some other ads weren't blocked.
3.txt
screenshot3

Local VPN mode & DNS request filtering enabled & pref.vpn.ipv6.disable enabled -
All ads are blocked.
4.txt
screenshot4

@ameshkov ameshkov modified the milestones: 2.9 R2, 2.10 May 19, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 22, 2017

Member

The log is so freaking weird, as if the whole 121.* subnet was not filtered.

Member

ameshkov commented May 22, 2017

The log is so freaking weird, as if the whole 121.* subnet was not filtered.

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 22, 2017

Member

Okay, I've got an idea.

Here are some key points:

  1. By default, we add the following IPv6 route: 2000::/3 which covers all the public IPv6 addresses.
  2. I see 6-4 and 4-6 tunnel network interfaces in the log (ip6tnl0 and sit0).
  3. I see that m.dcinside.com is resolved to 121.125.60.186
  4. I don't see any connections to 121.* subnet in the log as if nothing was routed through the VPN

What if IPv4 packets are being sent over a 4-6 tunnel? In this case, 121.125.60.186 would have been mapped to 0:0:0:0:0:FFFF:797D:3CBA and therefore it would have bypassed our IPv6 route (see point 1). This explains why the issue is resolved when we block IPv6 completely.

To check the idea we should add one more route for IPv6 to cover IPv4-mapped addresses: 0:0:0:0:0:FFFF::/96

Member

ameshkov commented May 22, 2017

Okay, I've got an idea.

Here are some key points:

  1. By default, we add the following IPv6 route: 2000::/3 which covers all the public IPv6 addresses.
  2. I see 6-4 and 4-6 tunnel network interfaces in the log (ip6tnl0 and sit0).
  3. I see that m.dcinside.com is resolved to 121.125.60.186
  4. I don't see any connections to 121.* subnet in the log as if nothing was routed through the VPN

What if IPv4 packets are being sent over a 4-6 tunnel? In this case, 121.125.60.186 would have been mapped to 0:0:0:0:0:FFFF:797D:3CBA and therefore it would have bypassed our IPv6 route (see point 1). This explains why the issue is resolved when we block IPv6 completely.

To check the idea we should add one more route for IPv6 to cover IPv4-mapped addresses: 0:0:0:0:0:FFFF::/96

@ameshkov ameshkov changed the title from Ads are not blocked until enabling pref.vpn.ipv6.disable to IPv4 mapped addresses bypass VPN May 22, 2017

@ameshkov ameshkov removed the filtering label May 22, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Jun 1, 2017

Member

@seanl-adg could you please ask user to test it with the latest beta version (and with default low-level settings)?

I've added IPv4-mapped addresses to VPN routes, so if I was right, the issue should be resolved now.

Member

ameshkov commented Jun 1, 2017

@seanl-adg could you please ask user to test it with the latest beta version (and with default low-level settings)?

I've added IPv4-mapped addresses to VPN routes, so if I was right, the issue should be resolved now.

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Jun 11, 2017

Member

@seanl-adg anything new?

Member

ameshkov commented Jun 11, 2017

@seanl-adg anything new?

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Jun 22, 2017

Member

It appears that my hack does not work (IPv4-mapped route was transformed to IPv4 anyway), I will look for a better solution.

06-22 20:53:11.328 604-665/? E/Netd: parsePrefix failed for destination 0.0.0.0/96 (Invalid argument)
Member

ameshkov commented Jun 22, 2017

It appears that my hack does not work (IPv4-mapped route was transformed to IPv4 anyway), I will look for a better solution.

06-22 20:53:11.328 604-665/? E/Netd: parsePrefix failed for destination 0.0.0.0/96 (Invalid argument)
@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Jun 26, 2017

Member

Added ::8000:0:0/81.

Member

ameshkov commented Jun 26, 2017

Added ::8000:0:0/81.

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Jun 26, 2017

Member

@seanl-adg here is a newer build with proper routes:
adguard_2.9.125_dev.apk.zip

Could you please ask people who suffer from the issue to test it?

Member

ameshkov commented Jun 26, 2017

@seanl-adg here is a newer build with proper routes:
adguard_2.9.125_dev.apk.zip

Could you please ask people who suffer from the issue to test it?

@ameshkov ameshkov modified the milestones: 2.10, 2.9 R2 Jul 17, 2017

@ameshkov ameshkov removed this from the 2.10 milestone Aug 23, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Aug 23, 2017

Member

No updates for quite some time, closing it.

Member

ameshkov commented Aug 23, 2017

No updates for quite some time, closing it.

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Aug 29, 2017

Member

Reopened due to #1393 (comment)

Member

ameshkov commented Aug 29, 2017

Reopened due to #1393 (comment)

@ameshkov ameshkov reopened this Aug 29, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Aug 29, 2017

Member

@veronikasav

Ticket ID: 1620465

Please ask the user if he's ready to try a test build and collect logs for us?

Member

ameshkov commented Aug 29, 2017

@veronikasav

Ticket ID: 1620465

Please ask the user if he's ready to try a test build and collect logs for us?

@veronikasav

This comment has been minimized.

Show comment
Hide comment
@veronikasav

veronikasav Sep 2, 2017

@ameshkov The user is ready. Which log exactly should we ask to collect?

veronikasav commented Sep 2, 2017

@ameshkov The user is ready. Which log exactly should we ask to collect?

@Eugene-Savenko

This comment has been minimized.

Show comment
Hide comment
@Eugene-Savenko
Member

Eugene-Savenko commented Sep 6, 2017

@vozersky

This comment has been minimized.

Show comment
Hide comment
@vozersky

vozersky Sep 6, 2017

Member

@veronikasav @evgeniy-ADG Adguard's "record everything" level log, just make sure not to send it to support from the app itself, but export it using the new beta's export feature and send by mail

Member

vozersky commented Sep 6, 2017

@veronikasav @evgeniy-ADG Adguard's "record everything" level log, just make sure not to send it to support from the app itself, but export it using the new beta's export feature and send by mail

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Sep 7, 2017

Member

Guys, the test build will be ready today

Member

ameshkov commented Sep 7, 2017

Guys, the test build will be ready today

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Sep 7, 2017

Member

Here you are:
adguard_issue1026_test1.apk.zip

IMPORTANT: I need to get the "record everything"-level log with this test build in any case (even it works okay, this is a temporary solution just to record the log)

Member

ameshkov commented Sep 7, 2017

Here you are:
adguard_issue1026_test1.apk.zip

IMPORTANT: I need to get the "record everything"-level log with this test build in any case (even it works okay, this is a temporary solution just to record the log)

@Eugene-Savenko

This comment has been minimized.

Show comment
Hide comment
@Eugene-Savenko

Eugene-Savenko Sep 7, 2017

Member

sent to the customer

Member

Eugene-Savenko commented Sep 7, 2017

sent to the customer

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Dec 4, 2017

Member

@evgeniy-ADG anything?

Member

ameshkov commented Dec 4, 2017

@evgeniy-ADG anything?

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov Dec 4, 2017

Member

Please reopen if any new information appears

Member

ameshkov commented Dec 4, 2017

Please reopen if any new information appears

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment