Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Chinese social media sites weibo and sina are being blocked #86

Closed
slammpete opened this issue Feb 25, 2023 · 13 comments
Closed

Chinese social media sites weibo and sina are being blocked #86

slammpete opened this issue Feb 25, 2023 · 13 comments

Comments

@slammpete
Copy link

do you have a dns server that blocks nothing? I am unable to reach the two biggest social media sites in china when using mullvad. When mullvad is disabled, i can reach them fine.

Please provide a dns that blocks nothing. no adware, malicious sites, etc... thanks.
@jbjorkang
Copy link
Member

All our VPN servers run their own DNS resolvers that do not block anything by default. Try using our service without any toggles set, or without using any custom DNS IPs.

@slammpete
Copy link
Author

yes when i turn off your app and use my providers DNS IP's i am able to reach the site with no problem. In your app, when i connect to certain servers i am able to use weibo but the latency is so high since i am in south america the only one that works well is miami, florda. if i switch to japan or anywhere in asia everything works fine. for now i have created a new firefox profile that uses my providers dns ip's instead of yours because your app lets me tunnel an app but not with an particular instance of an app since i have many firefox browsers running with different setups.

@flyxyz123
Copy link

flyxyz123 commented Mar 19, 2023 •
edited
Loading

Some chinese websites can not reach because some mullvad server's DNS sucks: https://www.reddit.com/r/mullvadvpn/comments/10sht67/open_chinese_search_machines/

I made a shell script to test if target mullvad wireguard server can reach www.baidu.com or not: https://codeberg.org/flyxyz123/public_archive_codes/src/commit/4d96b7d54f56d4371759c8b8d6fa5ef75e228043/sh/mrt

This script only test wireguard relays. It default outputs Los Angeles wireguard relays that can reach www.baidu.com to stdout and $XDG_DOCUMENTS_DIR/logs/mrt_los_angeles_www.baidu.com.log. Currently, the default outpus are:

us-lax-wg-101
us-lax-wg-102
us-lax-wg-103
us-lax-wg-104
us-lax-wg-301
us-lax-wg-302
us-lax-wg-303
us-lax-wg-401
us-lax-wg-402
us-lax-wg-403
us-lax-wg-404
us-lax-wg-405

Which means us-lax-wg-201, us-lax-wg-202, and us-lax-wg-203 can not reach www.baidu.com

If you want to test New York relays, you do mrt -l 'New York' which outputs:

us-nyc-wg-303
us-nyc-wg-501
us-nyc-wg-502
us-nyc-wg-503
us-nyc-wg-504
us-nyc-wg-505
us-nyc-wg-601
us-nyc-wg-602
us-nyc-wg-604
us-nyc-wg-605

If you want to test if New York relays can reach www.baomitu.com, you do mrt -l 'New York' -w www.baomitu.com

In the past, the situation is much worse and about more than half of the wireguard relays can not reach www.baidu.com. About two weeks ago the situation become better but still not all relays are good.

What's interesting is that recently us-lax-wg-202 can not reach store.steampowered.com which is not a chinese site. However, this does not seems like a DNS issue because drill store.steampowered.com gives ip. But can't reach chinese sites should be a DNS issue because you can't even resolve their sites.

My script may have false positive due to not enough curl time, you can change the curl time with -m ex: mrt -m 12 means 12 seconds

@slammpete
Copy link
Author

slammpete commented Mar 20, 2023 via email

@slammpete
Copy link
Author

slammpete commented Mar 20, 2023 via email

@slammpete
Copy link
Author

slammpete commented Mar 20, 2023 via email

@slammpete
Copy link
Author

slammpete commented Mar 20, 2023 via email

@flyxyz123
Copy link

flyxyz123 commented Mar 20, 2023 •
edited
Loading

i do not have the mrt command in my bin and does not work. i am on arch linux.

mrt is a shell script wrote by myself, you can copy the source code here: https://github.com/flyxyz123/config_local_arch/blob/master/home/xyz/.local/bin/mrt

@flyxyz123
Copy link

flyxyz123 commented Mar 21, 2023 •
edited
Loading

I'm not working for mullvad. I'm a hobbyist user, I don't have too much technical knowledge so my answers maybe incorrect.

if use another dns server like what some redditors suggested, doesn't that then make my traffic visible to my isp? so for example i changed one instance of firefox to use cloudfare and ran your command line to see if all was ok and it says i am "leaking dns" information. Does this mean now my isp can only see which sites i am visiting but not the traffic since i am still routing through our vpn?

All my following answers assume you are using default mullvad.

If you use 1.1.1.1, you will not have DNS problems visiting chinese sites. Only mullvad DNS have DNS problems visiting chinese site. My scripts is to test mullvad DNS when using mullvad DNS, not when using 1.1.1.1. This means if there's no problems other than DNS problems, if you use 1.1.1.1 and run my script, it will always show all mullvad servers can reach chinese sites.

If you use 1.1.1.1, your DNS query can be seen by cloudflare and your ISP, your traffic can not be seen by them. This means "your ISP can only see which sites you are visiting but not the traffic." You can do encrypted DNS to prevent your ISP to see your DNS query, but cloudflare can still see your DNS query, I'm not sure if mullvad enabled this by default if you set 1.1.1.1 as custom DNS server, and I'm not familiar with this. EDIT: I am not sure if ISP can see your DNS query when using mullvad and set custom DNS server as 1.1.1.1.

My choice is to not use 1.1.1.1, I use default mullvad DNS, and when there's a problem, I change mullvad server, my scripts is just tell me what servers are good.

@slammpete
Copy link
Author

slammpete commented Mar 21, 2023 via email

@flyxyz123
Copy link

flyxyz123 commented Mar 22, 2023 •
edited
Loading

I am not sure if ISP can see your DNS query when using mullvad and set custom DNS server as 1.1.1.1. I did more search and some people say that after set custom DNS server as 1.1.1.1, DNS query is inside the VPN tunnel, so ISP won't see your DNS query. (https://www.reddit.com/r/mullvadvpn/comments/o5pzv5/when_using_a_custom_dns_server_are_those_dns/) I also edited my old incorrect respond to avoid misleading anyone. If DNS queries are inside VPN tunnel, although cloudflare can see your DNS queries, I do not think it matters much tho.

@oskaralmlov
Copy link
Contributor

oskaralmlov commented Mar 22, 2023 •
edited
Loading

Allow me to fill in the blanks from the serverside of things.

On us-lax-wg-202 we cannot resolve www.baidu.com:

oskaralmlov@us-lax-wg-202:~$ dig www.baidu.com
[...]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19987
[...]
;; connection timed out; no servers could be reached
[...]

Let's figure out which servers are authoritative (responsible) for baidu.com:

oskaralmlov@us-lax-wg-202:~$ dig baidu.com NS +short
ns2.baidu.com.
ns7.baidu.com.
dns.baidu.com.
ns3.baidu.com.
ns4.baidu.com

Let's try resolving www.baidu.com by asking these servers directly:

oskaralmlov@us-lax-wg-202:~$ \
for hostname in $(dig baidu.com NS +short); do
> echo $hostname
> dig @$hostname www.baidu.com +short || echo "Timed out"
> done

ns4.baidu.com.
Timed out
ns2.baidu.com.
Timed out
ns3.baidu.com.
Timed out
ns7.baidu.com.
www.a.shifen.com.

It appears we can't reach the majority of the servers that are authoritative for this hostname.

Running the same task on a completely different server (se-sto-wg-009) yields very different results:

ns4.baidu.com.
www.a.shifen.com.
dns.baidu.com.
www.a.shifen.com.
ns2.baidu.com.
www.a.shifen.com.
ns3.baidu.com.
www.a.shifen.com.
ns7.baidu.com.
www.a.shifen.com.

Conclusion/Theorizing:

  • The authoritative servers for baidu.com appears to, from a DNS perspective, be configured correctly.
  • Some of our relays cannot reach the authoritative servers for baidu.com. Or the response from the authoritative servers can't reach some of our relays. Either way the relay sends a query and does not get a response.
  • Since the queries are leaving our relays as they should, we can't really do anything else. Someone or something is dropping our queries or the answers to our queries on the way. Speaking from experience this is most likely because there is some blocklist in use that is blocking traffic from known VPN IPs.

If you absolutely need to connect via a relay that can't resolve these domains you can configure a custom DNS to have your connections be routed through the relay but have DNS queries resolved by an external server. See the link below.
https://mullvad.net/en/blog/2021/4/15/support-custom-dns-servers-launched/

In order to get you the right support it's better to reach out to our support at support@mullvad.net since our support team does not have a presence on GitHub.

Hope this answers your questions :)

@slammpete
Copy link
Author

slammpete commented Mar 25, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@flyxyz123 @jbjorkang @oskaralmlov @slammpete