XTLS
Investigation on Blocking of Reality in IRAN - Test Results
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:
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."
👍 @RPRX We look forward to your valuable comments. You always provide the best solutions. We appreciate you. ❤️
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?
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.
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
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.
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.
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?
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
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.
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
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).
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.
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...
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
- TLS
- 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
SSHno 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.
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?
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
Does anyone know about rprx? There is no news of him for several days! I wish him health and well.
"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?
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 :
- Use your own NEW and FRESH domain name (steal oneself and not steal others)
- Do not use well-known vps providers like Hetzner, OVH, Linode, Leaseweb, Vultr, Microsoft, Amazon and ...
- Do no use server in well-known countries like Germany, France, Netherland, UK and US
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.
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.
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.
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 :
- Use your own NEW and FRESH domain name (steal oneself and not steal others)
- Do not use well-known vps providers like Hetzner, OVH, Linode, Leaseweb, Vultr, Microsoft, Amazon and ...
- 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 :
- The VPS was from Germany but it was not from a well-known provider.
- 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.
- 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:
- 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.
- 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.
"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.
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
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.
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
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 🌹❤
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，等等。
我比较关心两件事：
- CPU 使用率飙升时，来源 IP 有多少，它们是重放以前捕获到的 Client Hello 还是发不同的、全新的 Client Hello？
- 部署一个 REALITY 服务器但不用它作为代理，而是仅修改 host 为它的 IP、仅当端口转发使用会怎么样？
第二条更容易测试。
