Investigation on Blocking of Reality in IRAN - Test Results

[Phoenix-999]

Before delving into the issue concerning the reality protocol, I would like to make a couple of notes.

• As we are aware, the Great Firewall (GFW) employs various techniques to detect and block proxy servers. This discussion specifically addresses recent events involving the blocking of the reality protocol in Iran, primarily by MCI ISP.

• The information provided below is our speculation and arises from several users experiencing similar test results, raising suspicions about GFW's techniques and methods for identifying the reality protocol.

• Additionally, this issue is a continuation of the previous conversation regarding the blocking of reality. If you are new to this topic, I recommend reading the previous issues, which can be found at the following links:

Link 1 Link 2 Link 3 Link 4

Now, let’s delve into the matter.

Over the last five months, most Iranian users have encountered challenging situations, given that the reality protocol was the only one functioning seamlessly in Iran. Most other protocols were easily detected by the Great Firewall (GFW). It's a challenging task but still a viable choice.

Now, in the last 10 to 15 days, we are experiencing new waves of blocking Reality, which seem a bit different and more aggressive compared to the blocking waves of the past couple of months. We recently observed something that has been discussed before and rejected by many. Still, we believe that GFW, operating under MCI command, might have found a way to block reality by analyzing heavy traffic. We are not 100% sure, but our test results strongly suggest that these new waves of blocking are due to traffic monitoring by GFW. This is how we think GFW might find reality.

Test Conducted:

• We created two fresh VPS servers, correctly set up with all security measures in place. • Both servers had clean IP addresses in the same range, and SSH was done through VPN proxy to provide extra security. • In both servers, the reality protocol was created using the same port (443) and the same whitelisted SNI. •The only difference was that VPS number one was shared with only 5 to 7 people with low to medium traffic, while VPS number 2 was shared by more than 200 people, and heavy traffic was directed to it in a short period.

After about 2 hours, VPS number 2 was suddenly disconnected, and the CPU usage spiked to 100%, causing the server to temporarily disconnect. It then returned to normal percentage, but the IP was subsequently blocked by GFW. The screenshot below illustrates exactly what we experienced while using the reality protocol with heavy traffic. Of course, we considered the possibility of it being accidental, so we tried it multiple times with different users, and the same thing happened consistently.

Although VPS number one survived for about two days, after reaching a certain traffic point, we realized it was also blocked by GFW. Additionally, we had VPS number 03, which we subjected to very low traffic with one to two users. After a week, it was still running and had avoided detection by GFW. It's essential to mention that we took careful measures to implement security, blocking all domestic IPs and domains on the servers and bypassing them through VPN client applications. We used IP protection, random DNS switching, fragmentation, and many other techniques in our X-ray configuration to see if we could escape detection. However, every time the traffic reached a certain point within a specific period, GFW detected and blocked it.

After IPs are blocked by GFW, we can still conduct the SSH connection, as evidenced in the screenshots below. Additionally, even after MCI blocks reality, Shatel ISP follows suit; however, reality continues to function in some other ISPs. Once again, the above is our speculation, based on the same test results conducted by different users in various regions of the country.

While not certain, we offer some suggestions that might help reality withstand the GFW's new measures. Please forgive us in advance, as we might not be as technically proficient as many of the great people here. Consider utilizing advanced obfuscation techniques such as:

⚪ Decoy Traffic Ratio ⚪ Dummy Traffic Ratio ⚪ Traffic Padding ⚪ Adaptive Behavior ⚪ Dynamic Switching ⚪ Dynamic Switching Interval ⚪ Fingerprint Spoofing

We would be immensely grateful for any help, guidance, and suggestions from any of you.

🇮🇷 To all my fellow Iranians, we would greatly appreciate it if anyone could conduct the same test and share their results with us here for more clarity

@RPRX, we are eagerly and patiently awaiting your thoughts on this matter.

^{"Everything that has a beginning has an end. I see the end coming. I see the darkness spreading. I see death. And you are all that stands in his way."}

[Havard20009]

Nice job Thank you

[MrVb0]

👍 @RPRX We look forward to your valuable comments. You always provide the best solutions. We appreciate you. ❤️

[irgfw]

Both servers had clean IP addresses...

The problem is that we couldn't know if that's correct! Iran's GFW has a graylist containing many IP ranges from a year ago!

Did you have that IP address you stated clean from a year ago and did not implement obvious protocols like plain Wireguard, Shadowsocks, OpenVPN, and/or many other things other than Reality-tcp-vision ?

Before we buy a VPS IP address, maybe someone had Shadowsocks set up on the server! That would just put that IP address on the graylist.(or any other ancient and not safe proxies.)

And this is not solely just on Reality. if you set up a simple TLS proxy like vless-tcp-tls with flow=vision, it will be blocked if your IP address is on the graylist.

IRGFW has zoomed on TLS proxies now. all kinds of them. AND have a very large list of IP addresses (Gray List).

For example, we had many IP addresses that didn't have any traffic for 3 months on them but got blocked last week! and by traffic I mean the VPS server had no xray-core or panel or any VPN services...

---

By the way, the CPU usage report: It's interesting and others reported this! they are probably or likely Active-probes as we are investigating it. Did you check what was using the CPU? or strange IP addresses with many requests to the server?

[sambali9]

I think they are targeting the tls in tls features of the proxy flow (according to this paper) In my experience different vps providers have different levels of censoring. For example IPs from microsoft azure and google cloud have the least censoring and interference whereas IPs from hetzner have a very high censoring and interference.

In the paper mentioned above if the GFW allows for more false positives they could detect more xtls-vision traffic and my theory is that IPs from hetzner are set to have a very high false positives and servers from GCP or azure are set to have very low false positives. So hetzner proxies are more likely to be detected and blocked rather than GCP or azure.

[Fangliding]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive I have a friend who works at the Chinese Academy of Sciences, and they are currently in this situation In your country, it may not completely block all port forwarding, but rather judge based on the data traffic This is no longer related to fingerprints, so unfortunately we have no way to deal with it

[gfw-report]

Hi @Phoenix-999 and @irgfw,

Your report and findings fascinating to us. We'd be happy to help with this concerning situation. We are a group of researchers that have experiences on revealing the censorship mechanisms, such as real-time traffic analysis and active probing by the GFW of China, in the past few years.

If you think it's a good idea, we'd be happy to help investigate this situation, together with Xray developers and other anti-censorship researchers. We'd like to establish a more private communication channel to exchange information, but we couldn't find your email addresses. Can you drop us an email? Our email address can be found on our Github profile page.

We can still use this thread for public communication for transparency and to let more people aware of the situation in Iran and our latest progress.

[gfw-report]

Both servers had clean IP addresses...

The problem is that we couldn't know if that's correct! Iran's GFW has a graylist containing many IP ranges from a year ago!

Hi @irgfw , we agreed with you that we could not conclude that both servers have "clean" IP addresses without holding the IP addresses for a long long time; and there may be one thing to test:

Our understanding is that while @Phoenix-999's high-traffic volume server has been blocked, the low traffic-volumne server has not. @Phoenix-999 can now assign the low-traffic volume servers to more people to use. And if this server that hasn't been blocked for a while suddenly got blocked after getting high traffic volume, it shows evidence that traffic volume may indeed affect censors' blocking decisions.

We'd be happy to discuss more in detail and even help setup more controlled experiments.

[tobyxdd]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive

But how do you detect port forwarding? One server forwarding (reverse proxying) another would look exactly like the original with no way for a third party to tell, or am I missing something?

[Fangliding]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive

But how do you detect port forwarding? One server forwarding (reverse proxying) another would look exactly like the original with no way for a third party to tell, or am I missing something?

It's very easy For example, if you are using the Hetzner server but your dest is apple.com, it is obvious that Hetzner does not provide network services for Apple Other sites are similar, and there is evidence to suggest that Azure servers and Microsoft's CDN can also be distinguished, so don't have a lucky mentality

[sambali9]

overall I think Iran's gfw isn't really advanced , it's sh*t. all they can do is blocking as much IPs as possible from vps providers with high vpn traffic like hetzner. that's all they can do. their whole strategy is blocking most of these servers.

Reality on MCI is getting blocked on a large scale (having tested more than 10 reality servers with different configurations and SNIs) so GFW is advanced enough to block the Reality at least.

honestly I think reality is working fine. the issue is, so many Iranians were using speedtest.net as dest.(because it was the only site that worked fine with reality on some servers) and using this site as dest is very suspicious because when you do a speedtest it connects you to a sever within Iran , not outside Iran . so when the gfw sees the traffic of this site is going to a server for example in Germany, they can easily find out that sever is a vpn server.

www.speedtest.net is a website and anyone wanting to use it has to connect to cloudflare IPs outside of Iran, it doesn't matter if you test your speed with a server in Iran because you first connect to www.speedtest.net to get the server information and then connect to a different server with a different domain (most likely ending in ooklaserver.net) to test the speed.

[sambali9]

my question: did you have a sever that got blocked even though you(or the person who owned the IP before you) HAD NEVER used speedtest.net as dest on that server?

I used different SNIs (nixos.org, www.speedtest.net, my own domain etc..) all got blocked on MCI network

[MrVb0]

my question: did you have a sever that got blocked even though you(or the person who owned the IP before you) HAD NEVER used speedtest.net as dest on that server?

I used different SNIs (nixos.org, www.speedtest.net, my own domain etc..) all got blocked on MCI network

me too ! I tested different dest and sni on different servers, but the servers were blocked (within 2.3 days).

[sambali9]

did you use speedtest.net as dest on those servers? doesn't matter when , just tell if you have used it or not.

I used www.speedtest.net only for the server with www.speedtest.net SNI and used other servers with other dests relating to their respective SNIs. I have not used www.speedtest.net as an SNI or dest for other servers.

[irgfw]

Hi @Phoenix-999 and @irgfw,

Your report and findings fascinating to us. We'd be happy to help with this concerning situation. We are a group of researchers that have experiences on revealing the censorship mechanisms, such as real-time traffic analysis and active probing by the GFW of China, in the past few years.

If you think it's a good idea, we'd be happy to help investigate this situation, together with Xray developers and other anti-censorship researchers. We'd like to establish a more private communication channel to exchange information, but we couldn't find your email addresses. Can you drop us an email? Our email address can be found on our Github profile page.

We can still use this thread for public communication for transparency and to let more people aware of the situation in Iran and our latest progress.

Hi @gfw-report. great to hear from you. We are actively investigating new Iran's firewall behavior, especially in one of the operators named MCI (mci.ir) You can see some of our works here: https://github.com/GFW-knocker Also, I contacted you via email.

Hope we hear from you soon...

[shakibamoshiri]

Please do ask questions on this thread for configuration, etc
just share your test, there are other issues people asked but there is no thread for sharing tests

---

Guys do not zoom in to just X-Ray or Reality!

The targeted zone by MCI is not realty, it is any kind of SSL-VPN including

• OpenCoonect
• AnyConnect
• OpenVPN
• SSTP
• V2Ray if TLS is used
• X-Ray if TLS is used
• etc

which they have two key features in common

1. TLS
2. port 443

Here are what we know so far (TESTED)

• If you run WireShard it simply shows that TLS Handshake never completes (TCP RTO)
• a blocked IP while port 443 cannot be accessed the port 80 is fine
• since SSH no need for TLS it is fine even if the IP is blocked

how a server is detected (best guess)

• traffic pattern (VPNs traffic are close to 1-to-1 == symmetrical while normal sites are asymmetrical, 1-to-3, 1-to-10, etc)
• a website popularity (if it is a well-known, it is/should bot be blocked)

Clients (TESTED - Android)

Xray

OpenConnect

Client Pro

OpenVPN + obfs

SSTP

affected area (TESTED)

Those provinces protected more

• Kurdistan
• Tehran
• Zahedan

The Kurdistan MIC Phone numbers start with 0918-*-*** and Ardabil starts with 0914--*** . At the moment of this witting 0918- cannot access a server that is blocked while 0914 can access . So the issue/throttle differs from City to City.

[tobyxdd]

In fact, it is easy to easily block all connections of reality. Reality manifests as port forwarding (a relatively common service) to the outside. As long as GFW is willing to block all port forwarding, no reality connection can survive

But how do you detect port forwarding? One server forwarding (reverse proxying) another would look exactly like the original with no way for a third party to tell, or am I missing something?

It's very easy For example, if you are using the Hetzner server but your dest is apple.com, it is obvious that Hetzner does not provide network services for Apple Other sites are similar, and there is evidence to suggest that Azure servers and Microsoft's CDN can also be distinguished, so don't have a lucky mentality

It may be obvious to you in your specific example, but this requires someone to manually maintain a database of what IPs a domain should and shouldn't use for every single domain, and make sure it's always up to date no less. I seriously doubt this is the case.

Am I right in assuming that there isn't really an SNI whitelist in Iran, and the reason you guys use common domains like apple.com is just to look less suspicious? If random, niche domains (which certainly aren't in the database mentioned above, if it exists at all) are still allowed, has anyone tested the chances of getting blocked vs. using common domains like Apple & Microsoft?

[MrVb0]

It's very easy For example, if you are using the Hetzner server but your dest is apple.com, it is obvious that Hetzner does not provide network services for Apple Other sites are similar, and there is evidence to suggest that Azure servers and Microsoft's CDN can also be distinguished, so don't have a lucky mentality

me too ! I tested different dest and sni on different servers, but the servers were blocked (within 2.3 days).

did you use speedtest.net as dest on those servers? doesn't matter when , just tell if you have used it or not.

no , never

[MrVb0]

Does anyone know about rprx? There is no news of him for several days! I wish him health and well.

[its0ka]

"every time the traffic reached a certain point within a specific period, GFW detected and blocked it" why is this a secret? why can't you just tell the number?

[ashad765]

MCI is working perfectly fine in my area, so I can't test it myself. Can someone run a Reality server according to below and report results :

1. Use your own NEW and FRESH domain name (steal oneself and not steal others)
2. Do not use well-known vps providers like Hetzner, OVH, Linode, Leaseweb, Vultr, Microsoft, Amazon and ...
3. Do no use server in well-known countries like Germany, France, Netherland, UK and US

[The-Erf]

They are more stupid than this In my opinion, irgfw uses a much simpler method for identification. They might have a list of domains restricted to specific IP ranges. For instance, they might whitelist apple.com only for certain IPs, meaning operations won't proceed if the domain is correct but the IP isn't from Apple's actual range.

The second theory involves a simple test. For example, your server might use SNI like apple.com. Initially, irgfw checks your server's SNI and IP via a client hello. Then, it performs a basic ICMP ping or a DNS request to a reputable DNS server like Cloudflare or Google to see the IP behind that SNI.

If irgfw can detect a discrepancy between the actual IP of the site you SNI and your server's IP through a simple ping or DNS request, it might be able to block it.

(Note: They are confident that a reality behind a CDN can't stay hidden because even with a CDN, two simultaneous users might get two different IPs.)

However, considering the expanding number of websites, it's unlikely they can restrict all sites to specific IP ranges. Yet, it's a possibility.

In summary, I believe irgfw employs a simple mechanism for relative identification: checking the real IP behind your SNI and blocking if the SNI IP doesn't match your server's IP. Providers like Hetzner, DigitalOcean, Linode, and others may have a higher chance of being blocked.

[ashad765]

The second theory involves a simple test. For example, your server might use SNI like apple.com. Initially, irgfw checks your server's SNI and IP via a Hello client. Then, it performs a basic ICMP ping or a DNS request to a reputable DNS server like Cloudflare or Google to see the IP behind that SNI

According to this post this is exactly what happened with MCI right now. Iran GFW resolve SNI in tls client hello and forward Reality handshake to real SNI IP. It seems using your own domain is the only solution right now.

[ashad765]

Does anyone know about rprx? There is no news of him for several days! I wish him health and well.

I clearly remember that this happened last year too. RPRX was not active from September to the end of December.

[i4za]

MCI is working perfectly fine in my area, so I can't test it myself. Can someone run a Reality server according to below and report results :

1. Use your own NEW and FRESH domain name (steal oneself and not steal others)
2. Do not use well-known vps providers like Hetzner, OVH, Linode, Leaseweb, Vultr, Microsoft, Amazon and ...
3. Do no use server in well-known countries like Germany, France, Netherland, UK and US

Here is some details about one of my servers that got blocked by MCI :

1. The VPS was from Germany but it was not from a well-known provider.
2. The SNI was one of the Ookla(speedtest) servers that was close to my VPS, actually its server was in the same datacenter as my VPS.

First It got blocked by MCI after less than 100G traffic 2.5 weeks ago. After 2 weeks, I checked and realized that it's not blocked anymore and I started testing it. However after 3 days and traffic about 400-500G, it got blocked again by MCI. Accidentally the night before it gets block, I checked the cpu usage which was very unusual about 50% of a 2vCore VPS; I think something about Xray was consuming it. Probably it was an active-probing.

1. Use your own NEW and FRESH domain name (steal oneself and not steal others)

I know someone that used "steal-oneself " SNI more than once and also got blocked.

---

Using VLESS+TCP+RPRX-VISION+REALITY have become very hard in Iran. Many people are reporting this problem in our Iranian telegram groups. We assume that in some special cases we can still use this protocol:

1. Finding a VPS with a very clean IP that has not been used by others in the past for VPN(low-security protocols) in Iran. However, finding this kind of clean IP is not easy and most of us are disappointed in it.
2. Using whitelisted SNI which have become very hard to find and everyday this list is decreasing, so that some people sell the white SNIs they found by scanning.

[Phoenix-999]

"every time the traffic reached a certain point within a specific period, GFW detected and blocked it" why is this a secret? why can't you just tell the number?

About 40 GB in less than 2 hours. Conducting many more tests as we speak that's why we are waiting to make sure we share the right result from a variety of the users.

[Argo160]

Me and my friend having two servers from Hetzner running reality with no issue in past few months. The SNI used on those servers are speedtest and discord. So the theory of using speedtest and etc might cause the issue is not right. the monthly traffic of each server is between 2-3 TB. I believe Its all about the IPs whether they are on the MCI list or not. Funny thing is i used to have a few working IPs kept aside in hetzner ( I mean i tested them and they worked perfectly then Unassigned them) and after 2 months i tested them again. 3 of them out of 5 were blocked with zero traffic on them. and i guess the MCI randomly blocks and unblocks the IPs

[ghost]

after 2 months i tested them again. 3 of them out of 5 were blocked with zero traffic on them

Possibly they are applying a rule, such as, "If you find 6 proxy servers in the same /24, then block the entire /24." (I just made up those numbers as an example.)

It's possible that a combination of SNI, IP address owner, and traffic volume triggers a manual inspection. I still see people jumping to the conclusion that the protocol itself is what is getting them blocked. They believe that if only the protocol can be tweaked, they can go back to sending gigabytes and gigabytes to their Hetzner IP.

[opiran-club]

with respect to all experiences which you guyz sharing here, this is my experiences these days with mci at first like you all we thought problem is from sni or ip so we tested with our fresh real sni and fresh ip which im sure they were fresh but after 1 hour they were block by mci firewall so we extend our test and we saw that on that server which reality was run and it was blocked by mci we tried ssh tunnel and result was amazing and there was no blocking anymore so i think in this situation they are not blocking gray list they are blocking any ip which use reality

[opiran-club]

also there is an exception

amazon azure which mostly are clean in iran they work fine with reality and mci

this is proves that there is a gray list or if its not they monitor specific range ip. or specific region

really i dont have any expertise to analyse it but i keep testing and share with you guyz thats all i can do 🌹❤

[RPRX]

After about 2 hours, VPS number 2 was suddenly disconnected, and the CPU usage spiked to 100%, causing the server to temporarily disconnect. It then returned to normal percentage, but the IP was subsequently blocked by GFW. The screenshot below illustrates exactly what we experienced while using the reality protocol with heavy traffic. Of course, we considered the possibility of it being accidental, so we tried it multiple times with different users, and the same thing happened consistently.

这个测试结果很有趣，或许 MCI 怀疑它是 REALITY 服务器，所以用大量 IP 同时主动访问它并观察反应。由于 REALITY 服务器只有一个 IP，很快会被 dest 拉黑，或者它看的是临时套接字耗尽，或者它找到了 REALITY 服务端的代码实现 bug，等等。

我比较关心两件事：

1. CPU 使用率飙升时，来源 IP 有多少，它们是重放以前捕获到的 Client Hello 还是发不同的、全新的 Client Hello？
2. 部署一个 REALITY 服务器但不用它作为代理，而是仅修改 host 为它的 IP、仅当端口转发使用会怎么样？

第二条更容易测试。

[Phoenix-999]

After about 2 hours, VPS number 2 was suddenly disconnected, and the CPU usage spiked to 100%, causing the server to temporarily disconnect. It then returned to normal percentage, but the IP was subsequently blocked by GFW. The screenshot below illustrates exactly what we experienced while using the reality protocol with heavy traffic. Of course, we considered the possibility of it being accidental, so we tried it multiple times with different users, and the same thing happened consistently.

This test result is very interesting. Perhaps MCI suspected that it was a REALITY server, so it actively accessed it with a large number of IPs at the same time and observed the reaction. Since the REALITY server has only one IP, it will be destblocked soon, or it may see that the temporary socket is exhausted, or it may find a code implementation bug in the REALITY server, etc.

I'm more concerned about two things:

1. When CPU usage spikes, how many source IPs are there? Do they replay previously captured Client Hellos or send different, brand-new Client Hellos?
2. What if we deploy a REALITY server but don't use it as a proxy, but only modify the host to its IP and use it only for port forwarding?

The second one is easier to test.

Good to have you back, buddy. You got us worried for a bit, my friend. And, as always, thanks for your wisdom and input on the matter. We will be sure to share the results with you soon.

Ps: This place isn't the same without you.✌🏽

[RPRX]

Can you explain more about the tests?

第二条是为了探究 MCI 为何开始怀疑我们的服务器，第一条是为了探究 MCI 如何最终确定服务器是 REALITY（或端口转发）。

[sambali9]

In my experience for MCI doesn't get any spikes and the server get blocked after a few hours sometimes a few minutes. After MCI has blocked the server, other ISPs still can use the proxy and it works on other ISPs but not on MCI, after a while I get a big spike and then the server is blocked on other ISPs aswell

[sudospaes]

第二条是为了探究 MCI 为何开始怀疑我们的服务器，第一条是为了探究 MCI 如何最终确定服务器是 REALITY（或端口转发）。

您认为存在哪些可能性？

[amir-devman]

@RPRX,

I've figured out something really interesting which is very similar to things that @Phoenix-999 mentioned, or maybe that happened to me too and I didn't realize but this is what happened to me and how my servers I think is getting detected:

For the last 3 months before the massive blocking happened, every reality config for everyone was working with no problem and my servers started getting blocked on November 10, it just started there and since then I have seen massive Requests that I can see on Cloudflare Analytics & Logs. (There was some reality blocking on MCI before this massive block but it was nothing and no one could notice it)

The way that I configured my server is like this:

1. I have an HTTPS website on port 8443 which you can't access from outside and port 80 is redirected to 443 via Nginx
2. I set the "dest" of reality to port 8443, therefore I have my website and reality config on the same port which was working perfectly.
3. I've used my domain as my SNI and I've gotten a certificate for it.

I must say that I bought a new domain and a new server and it worked for almost 2 weeks without getting blocked. I've seen many people tell me that their IPs getting blocked within a day or less while my new setup was fine, but after 2 weeks this new setup got blocked too, but as soon as it gets blocked I changed the IP address multiple times and each time it didn't take more than an hour.

I've tried it with a different domain again and a full new setup, this time I've changed the Public/Private keys beside IP too, and it gets blocked a bit longer, like if it was 2 hours after that it was 24 hours or something...

Long story short, since this massive blocking started I've got hundreds of thousands of requests in a day and after I get blocked it just stops gradually, and when I look into where those requests came from, it's all from Iran, and a few requests from EU and US, while no one else except Iranian have that domain, and no one uses that domain/ip for real website, only reality config.

New domain that I bought:

Edit: All massive blocking that 100% blocked me in every way was happening on Fridays, note that I'm not in a Province like Zahedan, Kurdistan, or Tehran which GFW is something else there according to people saying.

[ashad765]

@amir-devman You are not stealing from others but it seems that your domain is behind Cloudflare CDN for nun-proxy clients. Try to ping your domain and you'll see Cloudflare IP and not your vps IP. Please turn off Cloudflare proxy and test again.

Can someone test VLESS and xtls-rprx-vision with normal TLS and not Reality like this config If MCI detection is all about Reality then normal TLS should survive.

[amir-devman]

@ashad765 That's not true, it's not returning CF IP. and I've never used any CF Proxy here.

[ashad765]

Ok. So all analytics and logs is just for DNS. Based on large DNS requests in a short period of time it probably indicate active probing. The big question is how iran gfw determine to active probing proxy servers. It would be very helpful if you could run below test :

1. Run VLESS and xtls-rprx-vision with tls and not Reality
2. Run Reality server with steal oneself and a static file server for web server. Then don't use it for proxy and only visit your domain and download files from it.

[mmrabbani]

@Phoenix-999 Have tested a Reality server after blocking suspicious IPs?

1. When CPU reaches 100%, Is there inbound connection from some suspicious IPs?
2. Could you please re-run the test after blocking some known active probing servers? here are two lists: https://alireza0.github.io/fa/docs/security/firewall/ https://t.me/irgfw/6

[Phoenix-999]

@mmrabbani,

We are currently conducting a variety of new tests, employing both active and passive searching across different VPS servers. As you may have noticed in earlier comments, with the assistance of the official @gfw-report team, members of @irgfw and other GitHub community contributors, we are tirelessly working to execute these tests and analyze the data. The process is taking some time as we aim to ensure that any results shared here are accurate and comprehensive.

This approach will enable knowledgeable members of the GitHub community to delve into the findings more deeply and identify visible and viable solutions. We appreciate your patience, and we will strive to present these results as soon as humanly possible. ✌🏽

[Amin2460]

Please do ask questions on this thread for configuration, etc just share your test, there are other issues people asked but there is no thread for sharing tests

Guys do not zoom in to just X-Ray or Reality!

The targeted zone by MCI is not realty, it is any kind of SSL-VPN including

• OpenCoonect
• AnyConnect
• OpenVPN
• SSTP
• V2Ray if TLS is used
• X-Ray if TLS is used
• etc

which they have two key features in common

1. TLS
2. port 443

Here are what we know so far (TESTED)

• If you run WireShard it simply shows that TLS Handshake never completes (TCP RTO)
• a blocked IP while port 443 cannot be accessed the port 80 is fine
• since SSH no need for TLS it is fine even if the IP is blocked

how a server is detected (best guess)

• traffic pattern (VPNs traffic are close to 1-to-1 == symmetrical while normal sites are asymmetrical, 1-to-3, 1-to-10, etc)
• a website popularity (if it is a well-known, it is/should bot be blocked)

Clients (TESTED - Android)

Xray

OpenConnect

Client Pro

OpenVPN + obfs

SSTP

affected area (TESTED)

Those provinces protected more

• Kurdistan
• Tehran
• Zahedan

The Kurdistan MIC Phone numbers start with 0918--* and Ardabil starts with 0914-- . At the moment of this witting 0918- cannot access a server that is blocked while 0914 can access . So the issue/throttle differs from City to City.

Thanks for your testing. Those data are useful. I ask you to do us a favor and gather more information 🙏

[Argo160]

Is it solved? or everyone agreed that reality is defeated by MCI? wondering why there is no feedback after all. Today almost all working reality servers got blocked by mci. The ones that were working for a long period of time and having super clean IP addresses.

[Mackcloner]

Is it solved? or everyone agreed that reality is defeated by MCI? wondering why there is no feedback after all. Today almost all working reality servers got blocked by mci. The ones that were working for a long period of time and having super clean IP addresses.

mine was working for about 120 days just maybe to change sni sometimes but none of these thing make my ip survive and its seems not work with any of SNIs bytheway with made good cover I had using Vless ws tls :/

[Phoenix-999]

I know time is always against us, and I'm sorry I took so long, but we wanted to be sure.

Following up on our discussion regarding the active blocking of Reality servers by MCI in the last three weeks: With the assistance of the GFW REPORT team & IRGFW, we assembled a small but capable team to conduct a series of different tests, analyze logs and data, and investigate the cause of detecting and blocking VPS servers.

Before we delve into sharing our findings, test results, and providing a summary of the conducted tests, along with our successes and challenges, it's crucial to discuss a broader perspective that will impact all of us in the near future.

It is imperative that we urgently address the recent substantial upgrade of the Great Firewall (GFW) in Iran, a development of significant importance unfolding over the last five days.

---

We have both positive and concerning developments to communicate. It is important to note that the information we are about to share is not yet fully confirmed. However, the majority of our case study results and evidence strongly suggest that this represents the new upgrade of the GFW.

Your active participation is crucial to either confirm or refute these speculations. We encourage you to share your experiences, contributing to a comprehensive understanding of the situation across the country. Your assistance is invaluable, as it enables us to provide a transparent and accurate report to the public.

As many of you may have already experienced and observed, there has been a notable change in the behavior of the Great Firewall (GFW) in the past five days. This shift underscores their active and unwavering efforts to employ any means necessary to disconnect individuals from accessing the free internet.

However, recent changes and upgrades, which involve the centralization and encryption of individual ISP data, indicate a shift. Moving forward, the GFW, spearheaded by MCI, will possess comprehensive access to all network communication and data across various ISPs. This centralized approach allows for the evaluation, analysis, and simultaneous blocking of any identified VPN protocols. Subsequently, the results are shared with other ISPs, leading to the blacklisting of VPS servers across the entire network.

The outcome of this recent upgrade is a considerably faster and more aggressive detection of VPS servers throughout the country.

The positive side of this upgrade is its revelation of numerous bugs and indiscriminate and blind targeting. This raises doubts about the GFW's ability to achieve 100% recognition of certain VPN protocols, such as Reality (we'll delve into that later, it is NOT Reality). Nonetheless, it manages to exploit server vulnerabilities and security leaks to identify connections, resulting in the subsequent blocking of VPS servers.

Over the last few days, there has been a notable increase in the simultaneous blocking of numerous VPS servers, particularly those situated outside Iran. In some cases, reports suggest that even local VPS servers have been affected. Among the servers facing restrictions, a considerable portion includes VPN servers, and a notable number comprises WEB servers, some of which are popular among the public users. Legitimate companies have voiced their concerns through reports and complaints, expressing worry about their web servers being blocked due to the utilization of foreign IPs for their services.

This brings some positive news amid the unfolding events. As we speak, we observe some members of the government and private company CEOs reacting with a bit of concern to these recent developments. They are urging the unblocking of some ISPs due to numerous errors and mistakes during the nationwide blockage of these foreign IPs.

Up until now, we are not entirely sure if these numerous bugs and indiscriminate and blind targeting are intentionally designed or if they are actual glitches in this upgrade.

Some of the new GFW changes are pretty scary. It's going to take the government more time and effort to make it happen. But, from what we've seen in recent events, this upgrade is no longer in the testing phase. It's in action, gradually rolling out across the country.

What's up with this upgrade? We believe the government started blocking a bunch of IPs to create a buzz and stir things up. The plan is for most of the legit web servers to eventually complain to their ISPs. Then, in the first part of the upgrade, the data is shared with the main database that the GFW has full access to NOW. After a thorough investigation and analysis of these web servers to make sure they're genuinely used as web servers, their IP addresses get added to a WHITE LIST. This is to avoid any errors and increase the accuracy to target the foreign IPs in future nationwide blockage.

As I mentioned, it will take a significant amount of time and resources for them to collect all this data and IP addresses. Nevertheless, they are actively starting this process.

Bear in mind that these new upgrades are part of a bigger plan and a darker picture, and they're implementing each step in specific phases. They're also learning from user group behaviors and the public reactions to these blockades, adjusting their actions accordingly. Already, most of the official government websites, which use foreign IPs, have been added to this WHITE LIST about five to six months ago to prevent any mistakes during the recent nationwide blockage.

Now, as I mentioned, these new upgrades are being implemented in different phases, and for the public, private entities, and individuals, we are starting to see a bigger picture that is much more concerning.

Another phase of these new upgrades is currently being experimented on individual VPN users in the past three months. To better understand this, let's step back and recall several key events that happened in the last 10 to 11 months. Then, we'll come forth to the present time to create a comprehensive picture for your better understanding and clarification.

About 12 months ago, many of us faced a sudden and seemingly enduring disruption of most VPN protocols. Experts commonly believed that security vulnerabilities in old protocols like OpenVPN and SSH made it easy for the (GFW) to detect and neutralize them. This led to widespread frustration and a prevailing belief that the GFW had a foolproof method to completely block these protocols.

It seems like there has been a suspicious shift in the VPN landscape. Over the past three months, many of these outdated and seemingly obsolete protocols have once again become operational. A considerable number of users, compelled by the pressing need for a functional VPN, have reverted to using these protocols. Interestingly, during this period, we've noticed that protocols with more robust detection mechanisms, employing strategic tactics to avoid the GFW's scrutiny, are now being aggressively targeted and blocked on a daily basis. It's noteworthy that the older and less sophisticated protocols continue to function without disruption.

This makes us think and raises lots of questions and suspicions, leading us to delve into these developments with experienced programmers and experts. Here is what most experts are thinking might be the motives behind the government's actions and the new upgrade of the GFW.

In the last three months, we've observed frustration, disappointment, and a sense of hopelessness among many users. They believe that protocols like X-UI or Reality Protocol, which had been reliable during tough times, may have come to an end. Additionally, we've noticed a growing number of users discouraging others from using these protocols.

The ongoing struggle of facing daily VPS blockades and the constant need to start over have compelled most users to seek an easier and more subtle connection. As a result, they've reverted to seemingly redundant protocols. Opting for these protocols is driven by the absence of interruptions or detection and the enjoyment of good speed performance, leading users to decide to stick with them!

The objective behind this new strategy and the GFW upgrade appears to be compelling 90% of users to revert to these protocols, for which they already possess a 100% foolproof solution to block. However, they seem to be deliberately allowing these protocols to function at this point, ensuring that users are not desperately seeking new solutions. The intention may be to prevent users from actively searching for and creating new protocols, which could pose a nightmare for the government.

In simpler terms, it's more effective to keep an eye on them than to capture them. Some might figure out a way to escape if they feel trapped. However, if they sense they're not confined, they won't struggle as much to find a way out.

I believe many of you now see the bigger picture and understand what is happening and what is about to come. It's not just about VPN protocols; it's a much larger and detailed plan. The focus is on changing the attitude of a generation that desperately needs to escape a hostile situation. The strategy is to crush hope, keep satisfaction at a minimum that serves the government's interests. When times get tough for them, they have the solution to force us into the dark ages.

The Iranian regime is primarily concerned about one thing: your innovative and creative minds. It's a facet of human nature that we often unite and harness our creativity and talent in the face of adversity and challenging situations. Only when we find ourselves metaphorically drowning, with no other option but to collaborate and push through the struggle, do our minds and talents truly shine. Over the last two to three years, many brilliant minds and experts, driven by the necessities of their daily lives, have devised strategies and solutions. These innovations have not only helped them but have also benefited millions of others facing similar challenges.

We Can Never Forget

No Matter How Much It Hurts

How Dark It Gets

How Far We Fall

We Never Out of the Fight.

---

📌 Stay tuned for our upcoming testing report and results in the next couple of days. We are committed to delivering valuable insights and will also guide you through essential cautionary measures to navigate the unfolding developments.

---

[sarinaesmailzadeh]

@Phoenix-999 First, I wanna appreciate you, you did a great job, and your information is very useful.

I want to share my information. I have a simple theory that if we change the public and private key and uuid every day the pattern inside of data will change, and it is much harder than before for GFW to recognize servers.

so I wrote a code that changes daily public and private keys and sends the new configuration to my telegram channel. people use these configurations for free. and I publish the traffic of my servers to my channel to investigate methods and traffic.

I gathering data from people from 5 Aug until now. and publish day by day all this information on my channel.

reality method was worked until 2 weeks ago. MCI detects my servers and blocks them.But my servers still work with other internet providers.

I switched to the Vmess method and changed public and private keys every.I don't know if this method is useful or not. But I try to test and investigate this method.

We never give up against a dictator

[shinya-dono]

Hi, and thanks for all of your efforts. I too have some interesting information to share.

following @Phoenix-999 theory about the government trying to keep an "eye" on VPNs, there seems to be a domestic IP range SPECIFICALLY for tunneling. From what I've heard from trusted/verified sources, under the control of the network security department of data centers, some IP ranges are allocated for tunneling and are sold to VPN dealers for tunneling purposes.

a common way of doing this is to chain a VLESS-TCP proxy without any security (plain HTTP) to a VMESS-TCP (also plain HTTP). the users are given the VLESS connection and the VMESS connection handles the firewall penetration task.

to my tests, this method works flawlessly. even under heavy loads of 200 to 300 concurrent users. the government also tried to prevent "any" domestic provider from hosting such servers by enforcing asymmetric traffic rules, meaning that except for a few, all hosting providers must keep their traffic ratio in the 1-4 to 1-10 range. this is applied to IP addresses. meaning that it is illegal for your domestic server to have a symmetric traffic ratio with any other IP, even if the server itself maintains the 1-10 ratio.

aside from that, it seems to me that passive detection only exists in userland. traffic made by domestic servers is not examined in passive methods like DPI and stuff (causing VMESS-TCP to work) but they still can trigger active probing (reality chain can get blocked in a few hours)

this concludes that the government, by any means IS encouraging users and VPN dealers to use domestic relays in order to "keep an eye" on them. considering the fact that only hosting providers that are okay with symmetric traffic ratio are the ones close to the government.

one more note is that to my surprise, VMESS-WS + Cloudflare proxy (plain HTTP) works very well without any IP/domain blocking.

[sarinaesmailzadeh]

based on @Phoenix-999 report I understood why the input traffic and output traffic of my servers are different. It 's work on other internet providers. It not worked on MCI.

Database updated: 2023-10-03 11:25:00

   eth0 since 2023-09-04

          rx:  2.78 TiB      tx:  2.66 TiB      total:  5.45 TiB

   monthly
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       2023-09      2.62 TiB |    2.51 TiB |    5.13 TiB |   17.41 Mbit/s
       2023-10    165.05 GiB |  158.26 GiB |  323.31 GiB |   12.98 Mbit/s
     ------------------------+-------------+-------------+---------------
     estimated      2.02 TiB |    1.94 TiB |    3.95 TiB |

   daily
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
     yesterday     67.43 GiB |   65.21 GiB |  132.64 GiB |   13.19 Mbit/s
         today     30.89 GiB |   29.51 GiB |   60.40 GiB |   12.62 Mbit/s
     ------------------------+-------------+-------------+---------------
     estimated     64.93 GiB |   62.04 GiB |  126.97 GiB |

This is one of my servers that I used a reality method and opened 40 ports for different SNI on it.

As you can see it transfers 132 GB of data in one day. My main question is why rx and tx are not the same. Where is 0.12 TB of data? I understand some clients can send requests to my server but when they don't get a response, GTW filters the response. 0.12 TB is huge data because when the client tries to check the server it consumes about 10 KB. it means that 12000000 users ( in 2 months) tried to access my server but they couldn't receive data.

[irgfw]

@sarinaesmailzadeh

you were correct if the GFW was just zooming in on Reality. But all other protocols like openconnect/trojan/ovpn/wg/softether/l2tp/ikev2/v2ray and ... are affected by this and the system just blocked some of the IP addresses. So it's not just Reality and has nothing to do with XRAY-Core.

And for that extra usage, it may be for OS update/upgrade or installing new packages, or downloading packages/scripts from GitHub as you monitor your entire eth0. So it will account for that.

[irgfw]

@shinya-dono

(reality chain can get blocked in a few hours)

It's not just reality. All other protocols are affected.

VMESS-WS + Cloudflare proxy (plain HTTP) works very well without any IP/domain blocking.

Of course, it works because GFW only sees the Cloudflare IP address and not the actual IP. So it can only block the Cloudflare IP address (which it did like last year).

[us254]

@sarinaesmailzadeh

I understand some clients can send requests to my server but when they don't get a response, GTW filters the response. 0.12 TB is huge data because when the client tries to check the server it consumes about 10 KB. it means that 12000000 users ( in 2 months) tried to access my server but they couldn't receive data.

Given that the server in question is being used as a proxy or VPN, the causes behind the discrepancy in rx (received) and tx (transmitted) traffic might relate primarily to the type of content being accessed and the nature of requests being made through it.

Asymmetrical Traffic Patterns: VPN and proxy usage typically involves clients sending requests for web pages, files, and other online resources through the server. The server then sends these resources back to the clients. However, the size of the responses (tx) is generally much larger than the size of the requests (rx) because the requested resources are often significantly larger than the request messages themselves. This can naturally result in more tx than rx data.

Censorship or Filtering: If an external censorship system (like GFW) is filtering the responses from the server, clients' requests are received by the server (counting towards rx), but the data sent back (tx) gets dropped or blocked by the firewall before reaching the clients.

When using a VPN/proxy server under heavy censorship, asymmetrical traffic patterns are common, and discrepancies can often be attributed to the filtering/censorship mechanisms in place.