A report on Iran's GFW

[sambali9]

Background

In recent months, Iran has started to heavily censor the internet and block most of mainstream VPNs and it seems that the GFW is updating about every week with more restrictions to the point that many innocent websites and IPs have their upload bandwidth restricted to under 1Mbps. As I'm writing this I haven't seen a complete report from Iran about the GFW that lets the outsiders know what is going on with the Iranian GFW so I'm hoping this report helps the outsiders to maybe understand the situation in Iran.

Disclaimer

This report is purely based on my experience and testing but some parts of it may not apply to everyone in Iran but I hope this is still a helpful report for the outsiders.

In this report when I say X didn't work It means that:

1. It gets blocked after a short while, and/or
2. It has a very slow upload speed and/or the browsing experience is very bad.

Iran has different types of censorship on different ISPs

In Iran, there are 2 most popular ISPs: MCI Hamrah Aval and MTN Irancell. These two are the most popular mobile careers and most of Iran's internet traffic is going through these 2 ISPs. There are other ISPs but these 2 have the strictest blocking out of all other ISPs. The GFW is different on MCI and MTN, for example, most of the IPs which are blocked on MCI work on MTN and vice versa, and also the proxy protocols that work on each one are different. Right now the only protocol which works for both is Xray's REALITY but I couldn't find any single VPS IP with REALITY which works for both and if one IP works for MCI it doesn't work for MTN even though the IP is accessible with both (Guessing Microsoft's azure IPs may work for both but haven't tested). Most all other ISPs like home wifi providers have similar GFW like MCI (if an ip is blocked on MCI it is most likely blocked on others too) but the blocking is not as strict as MCI. Another mobile carrier called Rightel seems to have the same GFW as MTN as the IPs which work on MTN also work on Rightel.

1) How is MCI's GFW?

MCI's GFW has been continuously updated about every week since the beginning. Every Tuesday I see that my proxies get blocked: when I deploy a proxy It works for one or 2 weeks but every Tuesday I saw my proxy stopped working so I changed the IP and used a more resistant protocol and it got blocked again on another Tuesday. First few months I used VMESS-WS then it got blocked so I used VLESS-TLS then got blocked I used VLESS-WSS-Cloudflare for a while then got blocked now I'm using REALITY and every Tuesday I'm anxious to see if it gets blocked or not. Other than the blocking MCI has implemented some sort of upload throttling which I guess is using whitelisted SNIs and IPs to decide to throttle the upload speed or not. When throttled the download speed is fine but the upload speed is under 1Mbps which makes loading more than a website/resource/image at a time very slow.

1.1) Proxy through Cloudflare

MCI's GFW has different branches for example it works differently on Cloudflare IPs and almost all other IPs. If the IP is from Cloudflare (AS13335) the GFW won't block the IP but instead, the SNI will be blocked if it detects a proxy. In recent months many Iranians started to use Cloudflare IPs from another AS called Cloudflare London (AS209242) which worked very well. Although not all IPs from CF London worked there were a few like 45.85.118.0/23 and 185.18.250.0/24 which worked well. By working well I mean they didn't get blocked (very rarely got blocked) and also the SNI would not get blocked if the IP got blocked and also the upload speeds were good. But for about the past month, these IPs have stopped working many got blocked and the unblocked ones have slow upload speeds. Right now some IPs still work but I have only seen IPs from AS13335 which would block the SNI if you run a proxy and it doesn't matter if it is GRPC or WS. My GRPC config that got blocked was pure Xray GRPC with no fake website or fallback and if you open it with a browser it would error 521 which I'm guessing is the reason why it got blocked or the GFW is detecting TLS in TLS. For WS I had a fake website and everything but still got blocked I'm guessing because of WS handshake.

1.2) Proxy through a VPS

As I said only Xray's REALITY is working but it is not as easy. First when REALITY got published if you set the SNI to yahoo.com you would get good upload speed on pretty much every VPS IP I tested but now for the past 2 weeks this SNI wouldn't work (it works with throttled upload like other protocols) but I have seen some VPS IPs that still work with yahoo.com or other whitelisted SNIs and I have a theory that the GFW has whitelisted these IPs because they had a lot of traffic with REALITY (or they hosted a high traffic innocent website and no proxies were running on them) and didn't get blocked before the past 2 weeks when GFW got updated.

1.3) UDP throttling

So far the protocols that I mentioned and worked were all on TCP because, since the beginning of this heavy censorship, the UDP upload were heavily throttled so far so when I made a call on Discord I had a problem understanding the other person and their voice would get chopped and robotic but if the other person used a TCP based protocol that had good upload speed the voice would be fine. The receiving of UDP packets was fine so if someone from outside talked their voice was fine. There also was a strange thing where if I changed the discord voice server from the Netherlands to Singapore the voices were fine on both ends. Now from about past 2 weeks, it seems that UDP upload throttling is no longer a thing but if I use KCP with Xray it would have good upload speed but it gets blocked after a while. I need to mention that for the IPs that REALITY has a slow upload speed if I use KCP, I get a good upload speed but the IP gets blocked after a while. A strange thing is that after the UDP throttling changed some of my friends can use Cloudflare WARP with really high speeds and some can't.

2) How is MTN's GFW?

Most of my experience is with MCI but I have a little bit of experience with MTN too but not much so I don't know the GFW history for MTN as I know for MCI but I still can report the current situation. From my testing and experience MTN's GFW doesn't block IPs but instead, it throttles them with about 50% packet loss no matter the protocol. So if you find a good IP with low packet loss and run REALITY with a good SNI it seems to work without a problem. You can even run a proxy with a fake HTTP header and a whitelisted Host header and it works fine and won't get blocked (it seems) but the speeds on REALITY are much better. MTN seems to have a protocol whitelist meaning that it blackholes the TCP connection based on the first few packets if they don't match HTTP or TLS and if it is a TLS connection it has to be a whitelisted SNI or it breaks the connection no matter what the TCP port is. This protocol whitelist is not present on MCI.

2.1) Proxy through Cloudflare

Since the beginning MTN blocked the VLESS-WSS-Cloudflare (haven't tested GRPC) on AS13335 but the IPs I mentioned above from AS209242 that worked for MCI also worked for MTN and they never got blocked until about a month ago (even though the same IPs got blocked after a long time on MCI) which all IPs have stopped working or at least I haven't seen any good CF IPs for MTN. Now if some IP works it has a very low speed.

2.2) Proxy through a VPS

As I said I haven't seen any IP get blocked on MTN but they get throttled to 50% packet loss (keep in mind I have very low experience using MTN) so the only thing that works is that I find IPs that have very low packet loss (like Microsoft's azure IPs) and run a REALITY server on them or I can even run a VLESS-TLS with a whitelist SNI and allowInsecure and so far it had good speed and didn't get blocked. I also need to mention it seems that the yahoo.com SNI is not in MTN's whitelist but there are other whitelisted SNIs that I rather not say publicly.

2.3) UDP throttling

I hardly tested UDP on MTN but here is what I found in my limited tests. The UDP throttling is strange on MTN, going back to the discord example some of my friends with MTN had a good voice quality, and others with MTN had very bad voice quality like with MCI on the same server at the same time and when they used proxies their voices had much better quality. I have also heard some friends are using OpenVPN UDP on MTN which I'm not sure how but they seem to be telling the truth (I haven't tested the OpenVPN UDP myself). I ran some KCP proxies myself and the results were very bad with low speeds or sometimes they didn't even get connected.

Conclusion

I hope this report helps outsiders understand Iran's GFWs better and if they experienced something similar in their country they could find this report useful. I also encourage other Iranians to share their experience with details so that we can have a more complete picture of the current situation.

[sambali9]

UPDATE: It seems it is unblocked now. Today (Tuesday) www.speedtest.net is blocked in Iran on MCI networks but it is unblocked on MTN and Rightel.

[operationairstrike]

I'm reading all this, thanks.

[hawshemi]

In Iran, the protocol doesn't matter. 90% of all VPS IPs are blocked or have 10x jitter/latency (50~80% packet loss)...

[sambali9]

In Iran, the protocol doesn't matter.

This is simply not true, if you use a good protocol like REALITY and properly configure it your proxy server will be unblocked much longer than if you use other more detectable protocols like direct Shadowsocks. If you are on MCI, if your server gets detected its IP will be blocked. If you are on MTN maybe you are right the protocol doesn't matter that much as it will not get blocked. Some MTN users may experience a protocol filter and in that case typical shadowsocks won't even connect and then you need to use TLS/http based protocols.

90% of all VPS IPs are blocked

Even though I don't have any numbers or data for amount of the blocked IPs, based on my experience there are way more unblocked IPs than just 10% and the blocking is usually high with popular hostings because many Iranians run weak and detectable protocols on their servers and the servers will get blocked. When I'm trying to find a hosting with IPs that have a low chance of being blocked I simply run RealiTLScanner on the hostings' IP range and if the hosting has a high number of blocked IPs I can see many of results from RealiTLScanner have a domain name with .ir in them and also the domain names are usually a dead give away that they are used for VPN and proxies for example: randomvpnshop.ir, akbarv2ray.xyz or mamadvmess.top (these are names that I came up with but its definitely possible to know if a domain name is used for VPN or not)

or have 10x jitter/latency (50~80% packet loss)

I have only seen this kind of packet loss on MTN networks but not on MCI networks which may suggest that your experience has been with MTN and not MCI and in case of MTN you are right.

[hawshemi]

This is simply not true, if you use a good protocol like REALITY and properly configure it your proxy server will be unblocked much longer than if you use other more detectable protocols like direct Shadowsocks...

By protocol doesn't matter, I meant the old protocols are just blocked by now by all of the ISPs. now we have just a few left like VLESS+REALITY. But when you cannot find a nonblocked IP address what good is it? OpenVPN or REALITY? :sweat_smile:

The REALITY is still in the testing phase. many many people reported that after using it for 1 week (even with one device!) their server IP address is blocked. (I think it's normal as the nature of REALITY could just expose the server ip which is stealing TLS) . This just hardens the finding for the nonblocked/clean IP addresses from hosting services...

because many Iranians run weak and detectable protocols on their servers and the servers will get blocked. When I'm trying to find a hosting with IPs that have a low chance of being blocked I simply run RealiTLScanner on the hostings' IP range and if the hosting has a high number of blocked IPs I can see many of results from RealiTLScanner have a domain name with .ir in them and also the domain names are usually a dead give away that they are used for VPN and proxies for example: randomvpnshop.ir, akbarv2ray.xyz or mamadvmess.top (these are names that I came up with but its definitely possible to know if a domain name is used for VPN or not)

Yes, exactly. many people ran SS or weaker protocols that lead to blocking the majority of IPs from famous hosting services. recently I found out MTN and MCI just block the whole range of IP by detecting ASN Numbers. For example, AS24940 for Hetzner is almost blocked in all ISPs. this is just odd and madness at the same time! (by blocked I mean the 50% packet loss for MTN and TLS Handshake timeout & EOF for MCI) Thanks for mentioning RealiTScanner. I have to test it to find some nonblocked ASNs. if you know more about finding nonblocked ASNs, please share it in some way!

I have only seen this kind of packet loss on MTN networks but not on MCI networks which may suggest that your experience has been with MTN and not MCI and in the case of MTN you are right.

Yeah. MTN does this. recently Zi-Tel started to do this (just increasing the latency by 5x-10x) with some very famous hostings like Hetzner.

Overall I tested ISPs:

Asiatech & Zi-Tel: The least amount of blockings. (even Wireguard and OpenVPN connect on Zi-Tel 😄 -but for now-) Shatel: brutal amounts of blocking. I tested a huge range of IPs on Shatel but most of them are simply just blocked. on the other hand, they will connect perfectly on MTN. MTN (4G & TD-LTE): very very odd behavior of blocking. they just block the whole ASN number! it's either blocked or 50% packet loss with 5x latency) MCI: Worked with some famous hosting services but not better than MTN. It's either working very well or completely blocked. Mobinnet: just like Asiatech & Zi-Tel but with little extra blockings!

(tested with: VLESS+XTLS+Vision + fake website sni + alpn:h2 + chrome/firefox fingerprint + allowinsecure:off) (VLESS+WS and VLESS+GRPC is just the same as XTLS+Vision in this regard)

[sambali9]

TLS Handshake timeout & EOF for MCI

For MCI networks I recommend using REALITY with a whitelisted SNI if the IP itself is not blocked maybe you should give REALITY a try as sometimes only whitelisted SNI may be accepted on some hosting (this may apply for Shatel too as it seems to have a similar GFW)

It's either working very well or completely blocked.

In my testings with MCI using REALITY some IPs will connect but with very low upload speed, another times you get an IP from the same subnet but using REALITY you can get good upload speeds and some IPs you can even use vmess+http and you will get a really good upload speed but it will get blocked shortly after.

[hawshemi]

Yep. Thanks. I experienced the low upload speed on a CDN config in which a blocked IP was behind Cloudflare's clean IP with VLESS+GRPC. even though the Cloudflare IP was a very good one, the upload speed was limited.

I think the main problem right now is finding clean IP ranges/services. as for protocols like vmess/vless are pretty good for not exposing the IP address hence the blocking. With clean IP and xtls+vision the probability of detecting & blocking the server IP address is very low (with a low number of users less than 20).

Do you have any suggestions/tools for scanning/finding clean IPs from ASN numbers and IP ranges?

[sh4run]

If possible, you guys may try a simple trick:

• setup an ssh tunnel over your existing proxy protocol
• running another proxy protocol (like ss or snell) over this tunnel.

This forms a "proxy overlay". Unlike proxy relay, all actual tcp connections are transferred in one tunnel in this case. This trick may be useful because my tests show GFW is likely sensitive to TCP connection establishment. Most GFW measures, like protocol/SNI recognition, happen in protocol handshake stage.

[MJamshidnejad]

Yep. Thanks. I experienced the low upload speed on a CDN config in which a blocked IP was behind Cloudflare's clean IP with VLESS+GRPC. even though the Cloudflare IP was a very good one, the upload speed was limited.

I think the main problem right now is finding clean IP ranges/services. as for protocols like vmess/vless are pretty good for not exposing the IP address hence the blocking. With clean IP and xtls+vision the probability of detecting & blocking the server IP address is very low (with a low number of users less than 20).

Do you have any suggestions/tools for scanning/finding clean IPs from ASN numbers and IP ranges?

How the server IP can be detected behind CF servers?

[hawshemi]

How the server IP can be detected behind CF servers?

It won't. But the GFW limits the CF IP addresses even with the best CF IP address for your ISP.

[victory7]

If possible, you guys may try a simple trick:

• setup an ssh tunnel over your existing proxy protocol
• running another proxy protocol (like ss or snell) over this tunnel.

This forms a "proxy overlay". Unlike proxy relay, all actual tcp connections are transferred in one tunnel in this case. This trick may be useful because my tests show GFW is likely sensitive to TCP connection establishment. Most GFW measures, like protocol/SNI recognition, happen in protocol handshake stage.

I'm using this method usually and it works well.

[MJamshidnejad]

How the server IP can be detected behind CF servers?

It won't. But the GFW limits the CF IP addresses even with the best CF IP address for your ISP.

Yeah. That's true. I confirm that on my behalf.

[ghost]

If possible, you guys may try a simple trick:

* setup an ssh tunnel over your existing proxy protocol
* running another proxy protocol (like ss or snell) over this tunnel.

@sambali9 Can you explain what you mean by "existing proxy protocol"? Are you implying there are now three layers, e.g. Shadowsocks over SSH dynamic port forwarding over Xray?

[sh4run]

@maerz22 Actually I wrote that piece and your understanding is correct. It is a 3-layer hierarchy: ss over ssh-tunnel over vmess/vless/or-whatever. This might not be easy for android/iphone users though.

[ghost]

@sh4run Sorry for the misattribution.

I can pass SSH through VLESS, but how do you pass Shadowsocks through SSH?

VLESS server

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 1234,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "d7c60b18-fa6d-4a05-8f35-bd1096e4907f",
                        "level": 0
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp"
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

VLESS client

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": "10808",
            "protocol": "socks",
            "settings": {
                "auth": "noauth",
                "udp": false,
                "ip": "127.0.0.1"
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "REMOTE.VPS.IP.ADDRESS",
                        "port": 1234,
                        "users": [
                            {
                                "id": "d7c60b18-fa6d-4a05-8f35-bd1096e4907f",
                                "encryption": "none",
                                "level": 0
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp"
            },
            "tag": "proxy"
        },
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

SSH client through VLESS client

ssh -D 8080 -o ProxyCommand='nc -x 127.0.0.1:10808 %h %p' ubuntu@127.0.0.1

[sh4run]

@maerz22 not "ssh -D", but "ssh -L". And you need an SS server installed on your remote vps. A reference can be found here.

[ghost]

Thanks. The SSH command above worked as a 2-layer version (SSH over VLESS). With your change, this works as a 3-layer version (SS over SSH over VLESS).

VLESS server

The VLESS server accepts input on port 1234. Since this is the underlying layer in the tunnel, port 1234 must be open for input in the server firewall.

Install Xray on the server using the script at https://github.com/XTLS/Xray-install:

sudo bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

Edit the xray server configuration file:

sudo vi /usr/local/etc/xray/config.json

Insert contents as follows:

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 1234,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "d7c60b18-fa6d-4a05-8f35-bd1096e4907f",
                        "level": 0
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp"
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

Restart the xray service:

sudo systemctl restart xray

VLESS client

The VLESS client accepts input on port 10808.

Install Xray on the client from https://github.com/XTLS/Xray-core/releases:

cd ~/Downloads
wget https://github.com/XTLS/Xray-core/releases/download/v1.8.1/Xray-linux-64.zip
unzip Xray-linux-64.zip

Edit the xray client configuration file:

vi config.json

Insert contents as follows:

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": "10808",
            "protocol": "socks",
            "settings": {
                "auth": "noauth",
                "udp": false,
                "ip": "127.0.0.1"
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "REMOTE.VPS.IP.ADDRESS",
                        "port": 1234,
                        "users": [
                            {
                                "id": "d7c60b18-fa6d-4a05-8f35-bd1096e4907f",
                                "encryption": "none",
                                "level": 0
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp"
            },
            "tag": "proxy"
        },
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

Run the xray client with your config.json:

./xray -c config.json

Leave the client terminal window open with the xray client running in it.

Shadowsocks server

The Shadowsocks server accepts input on port 8388.

On the server, install shadowsocks-libev from the repositories:

sudo apt install shadowsocks-libev

Edit the Shadowsocks server configuration file:

sudo vi /etc/shadowsocks-libev/config.json

Insert contents as follows:

{
   "server":"0.0.0.0",
   "server_port":8388,
   "password":"Xu5LafYPN88mQJqSd6nSYDrP",
   "method":"chacha20-ietf-poly1305",
   "mode":"tcp_only",
   "fast_open":false
}

Restart the shadowsocks-libev service:

sudo systemctl restart shadowsocks-libev

Shadowsocks client

The Shadowsocks client accepts input on port 1080 and sends output to the server which is apparently located on localhost port 8388. Later the traffic for localhost port 8388 will be sent through the SSH tunnel to the actual server port 8388.

Open a second terminal window on the client.

Install Shadowsocks on the client from https://github.com/shadowsocks/shadowsocks-rust/releases:

cd ~/Downloads
wget https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.15.3/shadowsocks-v1.15.3.x86_64-unknown-linux-gnu.tar.xz
tar -xvf shadowsocks-v1.15.3.x86_64-unknown-linux-gnu.tar.xz

Edit the Shadowsocks client configuration file:

vi ssclient.json

Insert contents as follows:

{
    "server": "127.0.0.1",
    "server_port": 8388,
    "local_address": "127.0.0.1",
    "local_port": 1080,
    "password": "Xu5LafYPN88mQJqSd6nSYDrP",
    "method": "chacha20-ietf-poly1305",
    "mode": "tcp_only"
}

Set the Shadowsocks client running in this terminal window:

./sslocal -c ssclient.json

Shadowsocks over SSH over VLESS client

Now open a third terminal window on the client.

The command below says: "SSH into the server as user ubuntu, using VLESS on localhost port 10808 as your proxy. Anything sent to 8388 locally should be forwarded through the SSH tunnel to 8388 on the destination server."

ssh -L 8388:127.0.0.1:8388 -o ProxyCommand='nc -x 127.0.0.1:10808 %h %p' ubuntu@127.0.0.1

Firefox

Open Firefox settings. Configure Firefox to use the SOCKS5 proxy on localhost port 1080 (i.e. the Shadowsocks client).

• Manual proxy configuration
• SOCKS Host 127.0.0.1
• Port 1080
• SOCKS v5
• Proxy DNS when using SOCKS v5

[free-the-internet]

@maerz22 Actually I wrote that piece and your understanding is correct. It is a 3-layer hierarchy: ss over ssh-tunnel over vmess/vless/or-whatever. This might not be easy for android/iphone users though.

What's the idea behind not using 2 layer (e.g. ssh over vless) but 3 layer (e.g. ss over ssh over vless)?

[sh4run]

The 2-layer(ssh over vless) is actually a 3-layer (socks5 over ssh over vless). Only both socks5 and ssh are provided by a single program "ssh". The major difference is, whether the traffic between the end device and local machine(socks5) is encrypted/password-protected or not. If the local machine is in your home, likely socks5-over-ssh-over vless is enough. The difference at server side is minor and possibly doesn't matter in most use cases.

[operationairstrike]

Mind-blowing

[free-the-internet]

The 2-layer(ssh over vless) is actually a 3-layer (socks5 over ssh over vless). Only both socks5 and ssh are provided by a single program "ssh". The major difference is, whether the traffic between the end device and local machine(socks5) is encrypted/password-protected or not. If the local machine is in your home, likely socks5-over-ssh-over vless is enough. The difference at server side is minor and possibly doesn't matter in most use cases.

If I'm understanding you correctly, you considered local Socks5 proxy as additional layer, but we only count layers of proxies only out of the gates of local PC. So, it must be 2; not 3. When you start SS, then it's 3.

[sh4run]

You are right. It is my misunderstanding.

[sambali9]

It seems that speed.cloudflare.com is being blocked: I tested it 4 hours ago and the Iran, Shiraz server was the only one which blocked it but now it is the Tehran server having it blocked

[sambali9]

Based on a report about Iran's internet situation most of accessible IPs are in a "Greylist" which throttles their upload bandwidth to up to 50% intentionally.

My experience: Some SNIs such as www.speedtest.net are whitelisted and their upload won't be throttled if used with any accessible IP using REALITY. Some Cloudflare and most of Microsoft, Google, AWS and Akamai IPs are whitelisted with no upload throttling.

[Phoenix-999]

It seems that speed.cloudflare.com is being blocked: I tested it 4 hours ago and the Iran, Shiraz server was the only one which blocked it but now it is the Tehran server having it blocked !

confirmed! we are experiencing the same thing. It seems Tabriz City Still working, But Shiraz and Tehran Blocked

[Phoenix-999]

17 July 2023 **Tehran Electronic Trade Association: Iran's internet is in the fifth row of low speed internet in the world**

In its new report, "Tehran Electronic Commerce Association" announced the "critical situation" of Iran's Internet quality and declared: "Among the 100 countries in the world with the highest gross national product, Iran has the second most disrupted Internet after Myanmar and the second after China." It is limited in the world and Iran's internet is one of the five slowest internets in the world. In its report, this association considered the main problem of Iran's Internet to be "widespread and permanent disruptions on almost all IPs and websites".

The Tehran Electronic Commerce Association, by examining 300 websites among 50 countries with the highest GDP, has come to the conclusion that Iran's Internet is at the top of the list of the most disturbed with 33% filtering and 18% disruption.The research of this association indicates that more than 33% of the world's top 100 websites are filtered in Iran, and Iran has the world's most restricted internet with 45% filtering.

At the same time, according to this report, among the 100 countries of the world, only Iran, China and Turkmenistan have blocked all six widely used social networks.The information contained in the report of the Tehran Electronic Commerce Association shows that in terms of the slowness of the Internet speed, Iran ranks third among the top 100 countries in the world (ranked 97 out of 100 in terms of speed and ranked 96 out of 100 in terms of delay). Is).

In terms of internet speed, only Cuba, Cameroon and Sudan are in a worse situation than Iran.

[wkrp]

17 July 2023 Tehran Electronic Trade Association: Iran's internet is in the fifth row of low speed internet in the world

Original report (Persian):

• https://etchamber.ir/گزارش-انجمن-تجارت-الکترونیک-تهران-درب/ (archive)
• https://etchamber.ir/wp-content/uploads/2023/07/Iran-Internet-v0.9.pdf (archive)

Sample page (page 7) from the censorship section:

The PDF report cites OONI repeatedly: page 4, page 5, page 6, page 16, page 20, page 35, page 37. The formatting in the PDF prevents me from copying and pasting text for a translation.

[operationairstrike]

17 July 2023 Tehran Electronic Trade Association: Iran's internet is in the fifth row of low speed internet in the world

Original report (Persian):

• https://etchamber.ir/گزارش-انجمن-تجارت-الکترونیک-تهران-درب/ (archive)
• https://etchamber.ir/wp-content/uploads/2023/07/Iran-Internet-v0.9.pdf (archive)

Sample page (page 7) from the censorship section:

The PDF report cites OONI repeatedly: page 4, page 5, page 6, page 16, page 20, page 35, page 37. The formatting in the PDF prevents me from copying and pasting text for a translation.

Why is Whatsapp and Telegram blocked in UAE?

[Phoenix-999]

@operationairstrike Because they don't want you to use the free phone call on any of those apps

they have strict rules to use a mobile phone only to make calls so they can charge you.

Basically any apps that have a free phone call or video call been blocked in AUE

[operationairstrike]

Bruh

[free-the-internet]

@operationairstrike Because they don't want you to use the free phone call on any of those apps

they have strict rules to use a mobile phone only to make calls so they can charge you.

Basically any apps that have a free phone call or video call been blocked in AUE

Instagram and Facebook messenger can do. Also lots of other apps. They are not blocked.

[Phoenix-999]

@free-the-internet The most popular VoIP applications that the UAE’s Telecommunications Regulatory Authority (TRA) has barred include:

Whatsapp FaceTime Skype Snapchat Viber Facebook Messenger

As of my last update, Dubai and the United Arab Emirates (UAE) had restrictions on certain apps and online services, particularly those that may violate the country's cultural, religious, or legal norms. These restrictions can include, but are not limited to:

VoIP (Voice over Internet Protocol) apps: Some VoIP apps, such as Skype, WhatsApp calling, FaceTime, and others, were restricted or had limited functionality to protect the interests of the local telecommunication companies.

Messaging apps: Apps like Telegram and others might face restrictions or limitations in their usage.

Social media platforms: Certain features of social media platforms, especially those that enable video calling or other forms of communication, may be restricted or have limited access.

VPNs (Virtual Private Networks): While VPNs themselves are not illegal in the UAE, using a VPN for illegal activities is strictly prohibited. Some VPN websites or apps may be blocked or restricted.

Dating apps and websites: Some dating apps and websites may be blocked due to cultural sensitivities. Content sharing and streaming apps: Apps like Snapchat, Reddit, and others might have restrictions or limitations on certain features.

[free-the-internet]

@free-the-internet The most popular VoIP applications that the UAE’s Telecommunications Regulatory Authority (TRA) has barred include:

Whatsapp FaceTime Skype Snapchat Viber Facebook Messenger

As of my last update, Dubai and the United Arab Emirates (UAE) had restrictions on certain apps and online services, particularly those that may violate the country's cultural, religious, or legal norms. These restrictions can include, but are not limited to:

VoIP (Voice over Internet Protocol) apps: Some VoIP apps, such as Skype, WhatsApp calling, FaceTime, and others, were restricted or had limited functionality to protect the interests of the local telecommunication companies.

Messaging apps: Apps like Telegram and others might face restrictions or limitations in their usage.

Social media platforms: Certain features of social media platforms, especially those that enable video calling or other forms of communication, may be restricted or have limited access.

VPNs (Virtual Private Networks): While VPNs themselves are not illegal in the UAE, using a VPN for illegal activities is strictly prohibited. Some VPN websites or apps may be blocked or restricted.

Dating apps and websites: Some dating apps and websites may be blocked due to cultural sensitivities. Content sharing and streaming apps: Apps like Snapchat, Reddit, and others might have restrictions or limitations on certain features.

Skype is popular among businesses. Blocking of it is a bit strange. Thanks for information.

[hawshemi]

Recently, strange things happened again on the infrastructure of Iran's internet. Many users with reality (and generally with all protocols) VPN reported that their server is limited by pure download/upload speed. it seems the GFW is restricting the speed of the IP address of servers. this happened to me for all of my servers from Hetzner and some Vultr VPSs. although users just changed their IP addresses this is rather new to Iran's GFW.

[mmmray]

For example, AS24940 for Hetzner is almost blocked in all ISPs

I have an IP from that range that works perfectly fine, and IME it is generally not hard to get an IP from Hetzner that works in most ISPs. At the same time VMESS also works fine for me so I don't know if I am just lucky. Bandwidth is severely limited though.

[mmmray]

It seems that speed.cloudflare.com is being blocked:

what is the site used in this screenshot?

[hawshemi]

Recently, strange things happened again on the infrastructure of Iran's internet. Many users with reality (and generally with all protocols) VPN reported that their server is limited by pure download/upload speed. it seems the GFW is restricting the speed of the IP address of servers. this happened to me for all of my servers from Hetzner and some Vultr VPSs. although users just changed their IP addresses this is rather new to Iran's GFW.

Update:

MCI is actively blocking/limiting vless/reality with almost all SNIs and configurations. Users reported that a simple SSH would work but Reality and other TLS tunnels are limited and/or blocked.

It's like Iran's GFW is upgrading or something.

[mmmray]

iran started blocking unencrypted HTTP+ws+vmess over cloudflare yesterday, according to reports of some users. however, traffic over that protocol continues to be high.

SSL over cloudflare didn't work for a while already. very simple tcp+vmess on hetzner continues to work fine for me even with very high bandwidth usage.

i believe there might be a connectivity difference between Hetzner Cloud IP pool and Hetzner Root Server IP pool. Cloud receives a lot more successful connections, but I have not heard of any problems with either.

vless/reality was blocked for me last week already. shadowsocks was blocked for some users since the start, but very little change there, I think that protocol might not be in anybody's focus right now.

[hawshemi]

Iran's GFW is indeed upgraded. it's now detecting actively blocking reality/tls/xtls/tcp IP addresses.

https://twitter.com/AminAnvary/status/1691575510436909122

[mmmray]

See also #277

[Phoenix-999]

Update:

It appears that the previously affected Domain/Subdomains that were Filtered & Blocked are now up and running again, and they've been unblocked!

We're a bit puzzled about the reasons behind these behavior, and We suspect that this might be in preparation for the anniversary of MAHSA AMINI and the people's uprising against the dictator regime from last year, but as of now, it's all speculation.

It's possible that The Iranian regime are conducting tests on the new system for a wider rollout. While we can't definitively pinpoint the cause, this turn of events is undoubtedly positive.

It would be greatly appreciated if someone could confirm these changes.

[Phoenix-999]

I've come across a new and rather strange issue that I wanted to share with you all. Just in case anyone else is experiencing the same phenomenon or perhaps has a reasonable explanation for it.

I've created a new VPS server using a clean IP, carried out my usual setup and configuration routine, and generated the Reality configuration with a clean and whitelisted SNI on port 443. (VLESS+TCP+Reality)

Everything appeared to be in order until I conducted tests across various ISPs and in different cities to ensure that everything is functioning correctly as it should. The client app and software are identical and up-to-date with the latest version.

Interestingly, the same configuration that was functioning flawlessly in cities like Tabriz, Isfahan, and Shiraz is no longer operational in Tehran, the capital city. This issue is observed across multiple ISPs in Tehran.

I've attempted various whitelisted SNI options, but the outcome remains the same, BUT when I’ve changed the port number from 433 to any 4 or 5 digit number the same config with the same SNI working in Tehran as well as other cities with consistent and decent upload and download speeds.

Has anyone else encountered a similar issue?

[Phoenix-999]

As I mentioned in my previous comments Buckle up your seat belt because the storm is about to start. 6 days left to anniversary of MAHSA AMINI**

⚠️Netblocks Confirmed: An internet disruption has been registered in #Iran for the second night in a row from ~1:00 am local time; Network data show connectivity falling down to 71% of ordinary levels 📉

[mmmray]

reports right now indicate that for the past week-or-so, censorship has been very light. cloudflare IPs got largely unblocked.

[Phoenix-999]

Hi everyone I've created this list and thought it might be helpful to include it in the IR routing rules.

Here is the List of 200 Iranian mobile Applications to Add to your geosite & geoip .dat Files. They've been organized in alphabetical order.

IR-Mobile-App-List.txt

"123tel", "a4f3clien", "abankefarda", "abank", "afaco.formool", "ako", "alachiigh", "alibaba", "alibaba.ir", "amirza", "anardoni", "anonycoders", "app.appaagah", "app.char", "app.fori", "app7030", "aparatspor", "aparattv", "app.gapkids", "app.hamrah", "app.hamyan", "app.igap", "app.leido", "app.mamana", "app.mydars", "app.padars", "app.pinno", "appchar", "artemis", "asantelegram", "asanbar", "asanapps.ariyagraph", "asparproject.app", "aspardproject", "ava", "baham", "bajet", "bajit", "bale", "balemessenger", "balonet", "bankino", "behkhaan", "behkhan", "bente", "bento", "bki", "blu", "bonakchi", "bonakchi.app", "bpm", "bsinew", "buyko", "carenboo", "cafe.telegraph", "calculationreal", "can.sel", "can.sell", "cartoonflix", "chabokpassenge", "cheebachee", "cheebachee.app", "cicika", "com.bize.irr", "combize", "cyklet", "cyklet.app", "daybank", "digikala", "digikala.firebol", "digikala.jet", "digilam", "digilam.app", "divar", "doozbin", "dorsabarza", "eghamat24", "efarda", "efar.da", "eitaa", "ela.mlaak", "eligasht", "enove.lingojoo", "esam", "esam.app", "esasy.live.memberbegirrubika", "etc", "express.snapp", "ezpay", "fadiaapp", "fam", "faraketab", "farakav.anten", "factorsabz", "fanoos", "fanoospfm", "fidibo", "filmnet", "filmischool", "flytoday", "football360", "footballi", "formool", "gardeshgari", "gardeshpay", "gahvare", "gapfilm.app", "gapkids", "gajino", "gajmarket", "gapfilm", "gapkid", "hamrah_mechanic", "hamrahbank", "hamrahcard", "hamrahelm", "hamrahnovin", "hoorsa", "homsa", "homsa.snapptrip", "hyperchi", "icup", "imino", "imino.pc.child", "iranapp", "iranmodernbusinesses.netbarg", "itoll", "itoll.mycarapp", "jadeh", "jadeh.driver", "jadeh.loadowner", "jajiga", "jajiga.app", "jama.ba", "jan.ebi", "karafs", "kalabis.hassan", "karnameh", "keshavarzi", "kilid", "kilid.portal", "kimiabiz", "learnit", "lenz", "lenz.tv", "likotv", "luna", "lunaapp", "mamana", "masterkala", "masterkala.shop", "melal", "melkana", "mehr.iran", "mehriran", "melkplus", "mibini", "mihmansho", "mobilemancard", "mobillet", "mydars", "mydigipay", "myiran", "myirancell", "myirancellcorp", "myrightel", "myshatel", "namava", "namava.mobile", "nasim", "navaco", "netbarg", "neshan", "neshan.traffic", "nichijou.app", "niazmandiha", "nobitex", "noonqeshm", "novinappsaz", "novinsimorgh", "partsoftware", "pasaj", "pasazh", "patogh", "patoghe_ketab", "payamakdoon", "paypod", "peccharge", "persiandesigners", "persiancalendar", "pikaap", "pinno", "pinno.app", "pindopin", "pindo", "pindo.fletcher", "pindopin", "pinket", "pinket.app", "pishkhan24", "quran", "qurankriampishgaman", "rayanmehr", "rezagem", "rizhav", "ronaksoftware", "roomack.amlaak", "rubika", "rubika.a", "sad24", "sad24.app", "sadadpsp", "safarmarket", "saramed", "sarmaye", "sarmayeh", "sekeh", "sepehr360", "set", "setareyek", "sesoot", "shahab_zarrin.quiz", "shahab_zarrin.tikup", "shahbaz", "shahbaz.zarrin", "shahbaz.zarrin.quiz", "shahbaz.zarrin.tikup", "shafa.doc", "shatel", "shatelland", "shatelland.namava.mobile", "shatelland.namava.tv", "shmapp", "shipnow", "sinamobilebank", "snapp", "snapp_box", "snapp.driver", "snapp.passenger", "snappfood", "snappfood.vms", "snappfoodvms", "soroush", "soroushmessenger", "stts.etc", "stts", "sunsetcar", "taaghche", "tabastaz.ir", "takhfifan", "takhfifhot", "takhfifhot.app", "taaghche", "tapsi", "taxi.tap30", "taxi.tap30.passenger", "tap30", "tap30.passenger", "tapsi", "tejarapp", "tejaratmobilebank", "tgbs", "tgbs.app", "tgbsgame", "tosansoha", "toranj", "torob", "toujib", "toujib.app", "wepod", "wepod.app", "yaramobile.pishvaz", "yma", "yootopin", "yotopin", "zabanshenas", "zabe amooz", "zamin.balonet", "zillow", "zillowmap", "zireh", "zoodfood", "zoodroom"

"The only thing necessary for the triumph of evil is for good Men & Woman to do nothing.” ✌🏾

Ps: It has already been shared with Bootmortis, XTLS/Xray-core, Loyalsoldier, v2fly/domain-list-community, and Chocolate4U. So, please do not share it with them again. Tnx

[Phoenix-999]

And struggle continues

Netblocks Confirmed: Live metrics show a significant disruption to internet connectivity in Zahedan, #Iran; the incident continues the weekly pattern of regional internet shutdowns targeting anti-government protests, and comes on the eve of the anniversary of Mahsa Amini's death

[Phoenix-999]

2023-09-23 Confirmed: An internet disruption has been registered in #Iran for the third time this month from ~1:00 am local time; Network data show connectivity falling down to 82% of ordinary levels 📉

[us254]

https://github.com/net4people/bbs/issues/253#issuecomment-1568162603

[Firefox] ---> [Shadowsocks Client]
    |
    v
(localhost:1080)

[Shadowsocks Client] ---> [SSH Client]
    |                                          SSH Tunnel
    v                                          (Encrypts and forwards traffic)
(localhost:8388)                             through VLESS on localhost:10808
                                                     |
[SSH Client] ---> [VLESS Client]                     |
    |                                                v
    v                                           [VLESS Server]
(localhost:10808)
                                                     |
[VLESS Client] ______________________________________|
    |
    v
(REMOTE.VPS.IP.ADDRESS:1234)

[SSH Server] <--- [VLESS Server]
    |
    v
(localhost:8388)

[Shadowsocks Server] <--- [SSH Server]
    |
    v
(0.0.0.0:8388)

• Firefox is configured to direct its traffic to the Shadowsocks client, running locally on port 1080. This is set up as a SOCKS5 proxy within Firefox's settings.

• The Shadowsocks client processes the traffic and forwards it to SSH client through a local port (8388). The Shadowsocks client encrypts the data as per its configuration before sending it on.

• The SSH client creates a secure tunnel to the VLESS client, using nc (netcat) as a proxy command to send data through the VLESS connection on port 10808.

• The VLESS client sends the encrypted traffic through the internet to the VLESS server on your VPS (Virtual Private Server) using the specified remote address and port (1234 in this case).

• Once at the VLESS server, the traffic is directed to the SSH server. The SSH server, running on the same VPS, is listening for connections and is ready to forward traffic to the specified local or remote ports.

• The traffic then moves to the Shadowsocks server through the SSH tunnel's port forwarding setup. The Shadowsocks server listens on port 8388.

• The Shadowsocks server finally processes the requests and sends them out to the internet. Responses follow the reverse path back to Firefox.

This 3-layer configuration (SS over SSH over VLESS) allows for enhanced security, obfuscation, and circumvention capabilities, especially useful in environments with heavy internet restrictions.

[Twantchydore]

In recent months, Iran has started to heavily censor the internet and block most of mainstream VPNs and it seems that the GFW is updating about every week with more restrictions to the point that many innocent websites and IPs have their upload bandwidth restricted to under 1Mbps.

I'm hearing reports that it's not currently possible to connect with VMESS and SSH protocol in Iran. Wanted to check if others are experiencing a similar situation and or if @sambali9 you plan to review your report a year on?