Iran's regime seems to have fully blocked WireGuard
Opened this issue · 18 comments
Hi,
WireGuard seems to be completely banned in Iran. No handshake is happening with servers outside the country.
I've heard about swgp-go but I don't know how to set it up. Can someone help us with this? Can clients on different OSs run swgp-go? If not, We have to run Wireguard with swgp-go from a VPS outside the country to a VPS inside it on Linux and use the second VPS (the one inside the country) to give clients access:
Clients ---normal WG---> Server1 (inside Iran) ---swgp-go WG---> server2 (outside Iran)
How could one configure such a setup?
I'm a beginner and therefore I'm not very educated about networking, proxies, routing, ... so please give me simple instructions and clear help on the configs needed if possible.
Thanks in advance.
all ssh type can be detected easily with the old DPI. use something that can be hard to monitor like naive proxy
it's a protocol that screams "I'm a VPN", with no stealth or obfuscation.
all ssh type can be detected easily with the old DPI. use something that can be hard to monitor like naive proxy
I don't think the mullahs are advanced enough yet to use DPI, I think they are just blocking protocols and my only goal is to somehow circumvent the blockage. Even if they find and ban my connection IDC because I use cheap burner VPSs on a monthly or even daily subscription.
Proxies with high obfuscation usually have 2 problems:
- low performance
- low versatility
it's a protocol that screams "I'm a VPN", with no stealth or obfuscation.
That's exactly the point of swgp-go. It hides the parts of the packets that are obvious and leaves other parts as they are and in this way produces minimal overhead from what I've read on their GitHub page.
The only problem is I'm a beginner and don't know how to set it up and there seems to be no tutorial anywhere for it.
Someone told me 2 days ago that Iran started blocking nearly all udp connections. I tested this hypothesis by simply using nc -u to connect to my server and I couldn't even send a single message.
Can anyone check if UDP packets can reach to their servers from Iran?
Can anyone check if UDP packets can reach to their servers from Iran?
I just now (2022-10-18 07:20:38 UTC) redid the DNS resolver scan from #125 (comment). (Scanning DNS resolvers in Iran from outside Iran.) I got responses from some resolvers in Iran, so UDP packets to at least those networks are not blocked.
$ while IFS=, read -r resolver_ip _ resolver_asn _; do echo -n "$resolver_asn $resolver_ip "; dig +short +time=1 +tries=1 @$resolver_ip unique-$RANDOM.example.com && echo NXDOMAIN; done < <(cat ir.csv | sort -g) | sort -g
6736 194.225.73.141 NXDOMAIN
12880 217.218.127.127 NXDOMAIN
15611 213.176.123.5 NXDOMAIN
43754 37.156.145.21 ;; connection timed out; no servers could be reached
43754 37.156.145.229 ;; connection timed out; no servers could be reached
43965 194.225.62.80 ;; connection timed out; no servers could be reached
48715 185.51.200.10 ;; connection timed out; no servers could be reached
48715 185.51.200.50 ;; connection timed out; no servers could be reached
49666 2.189.44.44 NXDOMAIN
50057 185.161.112.33 NXDOMAIN
50057 185.161.112.34 ;; connection timed out; no servers could be reached
56402 46.224.1.42 NXDOMAIN
56402 46.224.1.43 NXDOMAIN
56547 31.24.234.37 NXDOMAIN
58224 80.191.40.41 ;; connection timed out; no servers could be reached
58303 81.163.3.1 ;; connection timed out; no servers could be reached
60627 185.113.59.253 ;; connection timed out; no servers could be reached
60976 82.99.242.155 NXDOMAIN
60976 91.99.101.12 ;; connection timed out; no servers could be reached
202468 185.231.182.126 ;; connection timed out; no servers could be reached
202468 185.97.117.187 ;; connection timed out; no servers could be reached
209596 91.245.229.1 ;; connection timed out; no servers could be reached
212907 185.187.84.15 ;; connection timed out; no servers could be reached
ir.csv
194.225.73.141,,6736, 217.218.127.127,,12880, 213.176.123.5,,15611, 37.156.145.21,,43754, 37.156.145.229,,43754, 194.225.62.80,,43965, 185.51.200.10,,48715, 185.51.200.50,,48715, 2.189.44.44,,49666, 185.161.112.33,,50057, 185.161.112.34,,50057, 46.224.1.42,,56402, 46.224.1.43,,56402, 31.24.234.37,,56547, 80.191.40.41,,58224, 81.163.3.1,,58303, 185.113.59.253,,60627, 82.99.242.155,,60976, 91.99.101.12,,60976, 185.231.182.126,,202468, 185.97.117.187,,202468, 91.245.229.1,,209596, 185.187.84.15,,212907,
The Snowflake bridge is still getting traffic from Iran, which is WebRTC and therefore UDP.
I was able to use the DNS tunnel from #125 (comment) from a vantage point in Iran using 194.225.73.141 as an intermediate resolver.
Hi, author of swgp-go here. You can run swgp-go in client mode on server 1 and in server mode on server 2. The client accepts plain WireGuard packets and forwards the obfuscated/encrypted packets to the server, where they are deobfuscated/decrypted and sent to the WireGuard service.
Server 1 (swgp-go client) config:
{
"peers": [
{
"name": "domestic",
"wgListen": "[::]:20222"
"proxyEndpoint": "server2-ip:port",
"proxyMode": "zero-overhead",
"proxyPSK": "<same-format-as-wg-psk>"
"mtu": 1500
}
]
}Your WireGuard clients can connect to server 1's port 20222.
Server 2 (swgp-go server) config:
{
"interfaces": [
{
"name": "wg0",
"proxyListen": "[::]:20220",
"proxyMode": "zero-overhead",
"proxyPSK": "<same-format-as-wg-psk>",
"wgEndpoint": "[::1]:wg-port",
"mtu": 1500
}
]
}If you have more questions, feel free to ask here or open discussions at my repo.
If you have more questions, feel free to ask here or open discussions at my repo.
Thanks for your help. I'm afraid I don't even know where to begin with this as I'm very uneducated about all this.
One challenge is that because there is potential blockage, there is no room for trial and error (my main method of dealing with software and life really ...) because I wouldn't know if I'm making a mistake or the FW is blocking the attempts.
This is my typical WG configuration for chains:
https://www.reddit.com/r/WireGuard/comments/xr5nnr/comment/iqhqbqc/?utm_source=share&utm_medium=web2x&context=3
Do I need to change any of these 3 confs? (client, server1, server2)
How do I install swgp-go and even run it? Which parts of the above confs you kindly shared should I change to my specific credentials or addresses?
I fully understand if this is not what you normally answer and/or don't have time for but like I said, I'm just a newbie that has nothing to do with networking or IT for that matter and I'm just trying to provide myself, my family and my friends with free access to the Internet.
Thanks again for your help and your software.
@poorp while you are waiting for @database64128's reply:
If you have access to both a domestic server and a foreign server, you might try a domestic relay to a foreign Shadowsocks server.
It would be easier to configure, and Shadowsocks can be configured to use TCP only. That avoids the potential problem of a complete block on UDP.
Also, there are complete, end-to-end, step-by-step Shadowsocks turorials all over the web.
clowwindy's outline of the Shadowsocks relay process is at https://github.com/shadowsocks/shadowsocks/wiki/Setup-a-Shadowsocks-relay
If you need a full VPN, as opposed to a proxy server, you might consider something like OpenVPN + Cloak.
@freejohn123 The relay thing, although it works, it really doesn't. What I mean is: I can connect to SS and ping my server and even open Instagram or Telegram and enjoy a bit of freedom until I realise I can't upload any media on Telegram and Firefox or Chrome don't work at all for some reason (?). Also, even without the domestic relay the exact same results apply and the domestic relay doesn't seem to make any difference.
Very strange.
BTW, for my ShadowSocks server I used x-ui to set it up easily via a web-ui on my server which comes with a package of x-ray core amongst other things.
Well no matter what obfs and protocol you use, u can read chinese stuff here and learn the gfw, cause they are using it now and your traffic must look normal, so its better get less detected and make more vps available for others too. use hystera, naiveproxy or at least vless but don't use simple projects all of them have easy entropy to detect. and yes they are using GFW.
and yes they are using GFW.
NO THEY ARE NOT.
It is very similar but it's not the GFWoC.
I'm afraid I don't even know where to begin with this as I'm very uneducated about all this. One challenge is that because there is potential blockage, there is no room for trial and error (my main method of dealing with software and life really ...) because I wouldn't know if I'm making a mistake or the FW is blocking the attempts.
A piece of practical advice from someone also uneducated about computer networks -- with swgp-go, here's how I managed to guide myself:
Think of your packet flow like this: WG client <-> swgp client <-> swgp server <-> WG server <-> Internet.
WireGuard is just a connection, you don't need foreign network access to verify the connection. Just any Internet access through WG will do, and then you can repeat your validated process on a foreign server with much more certainty.
Step 1: play with a dummy swgp-go proxy
While the correct way to use swgp-go proxy is to have a client and a server, you can put both on your local computer to get familiar with its configuration. Make sure you can get WG client <-> swgp client <-> swgp server (local) working.
Step 2: try generic UDP with a server
Before trying swgp-go on an actual server, you want to make sure that UDP can reach the server at the port you intend for the proxy. WG being able to reach the server doesn't mean other UDP will -- this depends on the iptables config on your server and the firewall setting (if any) of your cloud provider. Do a quick read on the basics of NAT and iptables if needed.
This prepares you for swgp client <-> swgp server (actual).
I initially went from Step 1 directly to Step 3 and spent a ton of time scratching my head due to not realizing Step 2.
Step 3: play with an actual swgp-go proxy that is in the GFW
Assuming Step 1 and 2 worked, just migrate your process of running the proxy server to an actual server. You will need to change the proxy endpoint of your proxy client config, of course. If your connection through the proxy can reach any Internet site at all, your proxy is working.
This gets you WG client <-> swgp client <-> swgp server <-> WG server <-> Internet (GFW'ed)
Step 4: repeat Step 2 and 3 on a foreign server
This should be simple now. As a side note, for repeating Step 2 you can get 2 foreign servers and try UDP between them. This way you rule out GFW in your UDP troubleshooting.
This gets you WG client <-> swgp client <-> swgp server <-> WG server <-> Internet (full)
@fleurauxdents thanks for the detailed instructions specially since swgp-go lacks extensive documentation.
I will try this ASAP but for the time being here is some info I have gathered:
Iran's regime seems to have fully dropped UDP and not just WireGuard so swgp-go is most likely not going to work since it's UDP as well.
For now, I'm tunneling WireGuard through wstunnel and it works pretty well for the most part. I also tried udp2raw (icmp mode) which worked on most of my servers but on my main server it has a very low connection speed which is very strange and I couldn't for the life of me fix it (tried lowering mtu and using the recommended options with no luck).
Also, on a side note, none of these methods really work for gaming since the obfuscation and multi-hop structure add a lot of latency and stability issues. Proxies (likes of v2ray) are not perfect either and have many issues specially when it comes to gaming and tunneling UDP traffic. There is no hope for the games getting unblocked either since Iran's regime has never in the past 43 years unbanned something they banned. In conclusion, sadly, no gaming for now.
@fleurauxdents thanks for the detailed instructions specially since swgp-go lacks extensive documentation. I will try this ASAP but for the time being here is some info I have gathered: Iran's regime seems to have fully dropped UDP and not just WireGuard so swgp-go is most likely not going to work since it's UDP as well. For now, I'm tunneling WireGuard through wstunnel and it works pretty well for the most part. I also tried udp2raw (icmp mode) which worked on most of my servers but on my main server it has a very low connection speed which is very strange and I couldn't for the life of me fix it (tried lowering mtu and using the recommended options with no luck). Also, on a side note, none of these methods really work for gaming since the obfuscation and multi-hop structure add a lot of latency and stability issues. Proxies (likes of v2ray) are not perfect either and have many issues specially when it comes to gaming and tunneling UDP traffic. There is no hope for the games getting unblocked either since Iran's regime has never in the past 43 years unbanned something they banned. In conclusion, sadly, no gaming for now.
When you say they fully drop UDP, you mean all UDP traffic except for UDP port 53 for plain text DNS, right?
When you say they fully drop UDP, you mean all UDP traffic except for UDP port 53 for plain text DNS, right?
Yes that is exactly what I've heard.
I've tried port 53 for WireGuard but it doesn't work without obfuscation.
@fleurauxdents @database64128 I tested swgp-go extensively (it's actually pretty easy to set up).
It works between two domestic servers or two foreign servers but not with a foreign and a domestic server.
Step 2: try generic UDP with a server
(also @lulMeow ) I tried iperf with udp mode and if my foreign server is set as "server" data seems to somewhat flow but I get the "Ack not received" error and if the domestic server is set as "server" it shows no sign of getting anything so I guess UDP is out of the window.
I will be opening an issue as a feature request on the official swgp-go repo for some kind of faketcp, icmp or else like udp2raw does but with less overhead and optimized for WireGuard.
I'm also going to make a beginner's guide for dummies on how to set up swgp-go as well as videos on Odysee and YT because I think it's an awesome app even tho didn't work in my case.