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.

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

China GFW blocking shadowsocks (other ports/services work) #2288

Closed
pjrobertson opened this issue Feb 19, 2019 · 12 comments
Closed

China GFW blocking shadowsocks (other ports/services work) #2288

pjrobertson opened this issue Feb 19, 2019 · 12 comments
Labels

Comments

Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
@pjrobertson
Copy link

@pjrobertson pjrobertson commented Feb 19, 2019

What version of shadowsocks-libev are you using?

Server: shadowsocks-libev 3.2.3
Client: shadowsocks-libev 3.2.3 / Shadowsocks-NG 1.8.2

What operating system are you using?

Server: Ubuntu 16.04
Client: CentOS / MacOS 10.14.2

What did you do?

Been using the server as a shadowsocks proxy for 1-2 years no problem (set up using streisand and default settings). As of last week the shadowsocks connections are being blocked. I tried re-installing shadowsocks-libev from scratch (by re-running streisand) and making sure I'm using the latest ciphers, yet still not working. Since the server was set up 2 years ago, the Encryption type was aes-256-cfb (I know this was kind of old - may be an explanation as to how the GFW managed to block the server)

Also tried installing simple-obfs on the server/client and using that.

What did you expect to see?

A working shadowsocks from within China.

What did you see instead?

All shadowsocks connections are being blocked when trying to connect from a China based IP. Tried multiple encryptions (aes-256-cfb and chacha20-ietf-poly1305), also different ports (8530 and 8540).
Connecting from servers outside of China works no problem.

HTTPS / SSH are all open, so the server IP itself isn't being blocked, just the Shadowsocks protocol. simple-obfs with http is also being blocked.

What is your config in detail (with all sensitive info masked)?

{
    "server":"A.B.C.D",
    "server_port":8530,
    "local_port":1080,
    "password":"pass",
    "timeout":600,
    "method":"chacha20-ietf-poly1305",
    "fast_open":false,
    "plugin":"obfs-server",
    "plugin_opts":"obfs=http"
}

I'm happy to provide the server details, so that others can debug. To me this looks like a GFW getting smarter at determining what is a shadowsocks connection, and what isn't.

@madeye
Copy link

@madeye madeye commented Feb 19, 2019

  1. Try FTP/HTTP/HTTPS ports.
  2. simple-obfs is already deprecated. Try https://github.com/shadowsocks/v2ray-plugin and https://github.com/shadowsocks/kcptun
  3. Recent blocking has nothing to do with protocols, any suspicious ports and traffic from popular VPS providers are all blocked.

@pjrobertson
Copy link
Author

@pjrobertson pjrobertson commented Feb 19, 2019

Double checked, and turns out it was a simple IP + port block. When I previously tried changing ports I'd forgotten to open up the new port in the firewall. After opening the port things worked.

I guess the question here is: how did the GFW know to block that port? Was it a simple hard-coded rule "port 8530 is a common shadowsocks port, so block it" or what there something cleverer? I'll see if the new port gets blocked.

Thanks for the quick response @madeye , and for all the work you're doing on this project :)

@madeye
Copy link

@madeye madeye commented Feb 19, 2019

Fully encrypted traffic with very high entropy is obviously suspicious. Please refer to https://github.com/isofew/sssniff for more details.

@madeye madeye closed this Feb 26, 2019
@zzws524
Copy link

@zzws524 zzws524 commented Mar 1, 2019

I encoutered same issue. I have exact same settings for 2 different ports. After one port was blocked, I switched to the other one. It's working without changing anything on the server side.

The config json file like this:
...
"port_password":{
"9003":"passport1",
"9002":"passport2"
},
...
So I decided to alway keep two unblocked port in use.

The encryptions I used was an old one (aes-192-cfb). I am not sure if I choose a newer encryption, GFW would take longer time to detect my ss.

@desmax
Copy link

@desmax desmax commented May 15, 2019

already experienced this 2 times. it just blocks my port.
my encryption is aes-256-cfb

@pjrobertson
Copy link
Author

@pjrobertson pjrobertson commented May 15, 2019

I no longer have any issues with the GFW. Try disabling any plugins (obfs). Here's my config:

{
    "server":"A.B.C.D",
    "server_port":8530,
    "local_port":1080,
    "password":"abc",
    "timeout":600,
    "method":"chacha20-ietf-poly1305",
    "fast_open":false,
}

@metalbreeze
Copy link

@metalbreeze metalbreeze commented Jun 13, 2019

What i met is different:
June 10, my (only Encrytion chacha,no Obfs &no Protocal.) + my friends ss , those ips were blocked suddenly . I guess there was a gfw upgrade.

After sniffed suspect traffic , GFW do a detect , after “somehow” confirm, all traffice start to block ,even ping.
GFW will also do more detects in few mins, if no suspected port(i reboot the vm) , the traffice will be normal.

snap445(a detect, because i just setup a SS on a vm with a new ip at a port,no one knows before)

snap433(start to block, after SS stopped , all traffic will be normal)

After using AES-256-cfb simple_http auth_sha1_v4 , it seemed there are still incoming detects, but gfw can not desiced if it is ss or not. So, won't block anymore.

@eldoonreval
Copy link

@eldoonreval eldoonreval commented Sep 17, 2019

What i met is different:
June 10, my (only Encrytion chacha,no Obfs &no Protocal.) + my friends ss , those ips were blocked suddenly . I guess there was a gfw upgrade.

After sniffed suspect traffic , GFW do a detect , after “somehow” confirm, all traffice start to block ,even ping.
GFW will also do more detects in few mins, if no suspected port(i reboot the vm) , the traffice will be normal.

snap445(a detect, because i just setup a SS on a vm with a new ip at a port,no one knows before)

snap433(start to block, after SS stopped , all traffic will be normal)

After using AES-256-cfb simple_http auth_sha1_v4 , it seemed there are still incoming detects, but gfw can not desiced if it is ss or not. So, won't block anymore.

thanks for the information. will change it to aes-256-cfb to see if more IPs will be blocked!

@OrangeKnife
Copy link

@OrangeKnife OrangeKnife commented Sep 23, 2019

Same here
At first, ports are banned ( I changed a few times)
then Ip is banned
Fuck it.

@shubhvachher
Copy link

@shubhvachher shubhvachher commented Sep 23, 2019

Same as @OrangeKnife... First port ban and if you just change ports multiple time (4 times for me I think), you get an IP ban. Warning, for whoever comes across this thread.

@metalbreeze , could you please clarify on what you mean by

...using AES-256-cfb simple_http auth_sha1_v4...

Do you mean AES-256-cfb with a simple http obfs using plugin (obfuscating)? What do you mean by use auth_sha1_v4 then?

@niuzb
Copy link

@niuzb niuzb commented Sep 26, 2019

any update, my SS also been blocked today, after changing the port, still been blocked after a while

@nadimaj
Copy link

@nadimaj nadimaj commented Oct 29, 2019

And there goes my last life line. The barstewards first increasingly made it unreliable but today it's totally gone. ShadowSocks is not bulletproof like I thought. If your server is hosted with a popular hosting company, only a matter of time until they work out what's going on.

@shadowsocks shadowsocks locked as off-topic and limited conversation to collaborators Oct 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.