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.

[Havard20009]

Nice job
Thank you

[Kingahmad001]

https://rubika.ir/Tork__15__16

[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.

[mkh1364]

[Perlover]

Hi,

Don't you think that identifying the IP address where X-Ray is running or which is the actual public server (www.microsoft.com and etc) - can be easily determined by reverse IP address resolving?

That is, the GFW monitors TLS traffic. It checks first of all addresses with high traffic volume, and then does rozolving (PTR record, in Linux you can use dig -x IP command) and by reverse domain identify. For example, for real www.microsoft.com addresses we see a following pattern:

$ dig a microsoft.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> a microsoft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10807
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;microsoft.com.			IN	A

;; ANSWER SECTION:
microsoft.com.		3030	IN	A	20.112.250.133
microsoft.com.		3030	IN	A	20.231.239.246
microsoft.com.		3030	IN	A	20.76.201.171
microsoft.com.		3030	IN	A	20.70.246.20
microsoft.com.		3030	IN	A	20.236.44.162

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 04 11:30:10 CET 2024
;; MSG SIZE  rcvd: 122

$ dig -x 20.112.250.133

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> -x 20.112.250.133
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51594
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;133.250.112.20.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
250.112.20.in-addr.arpa. 218	IN	SOA	ns1-02.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300

$ dig -x 20.231.239.246

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> -x 20.231.239.246
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43046
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;246.239.231.20.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
239.231.20.in-addr.arpa. 84	IN	SOA	ns1-09.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300

;; Query time: 8 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 04 11:30:30 CET 2024
;; MSG SIZE  rcvd: 142

Here we can see the pattern that for IP addresses of real microsoft.com at least there is a pattern - SOA record has email (ns1-09@azure-dns.com) & primary DNS (azuredns-hostmaster.microsoft.com) from microsoft.com zone. Wherever you bought a VPS, it is hard to fake these SOA records by pointing them to microsoft.com servers as well. Often VPS providers, if they allow you to change the PTRs, they only allow you to change them to domain names that also resolve back to the same IP addresses. But in this example, there are no PTR records, but there is a SOA record for the entire reverse zone.

So, if your VPS responds only to port 443, pretending to be a public server www.microsoft.com, then if somebody set a simple task for GFW - find out if this IP really belongs to a pool of Microsoft servers, it will be easy to do it by reverse resolving, just by analyzing SOA and PTR records for the IP or reverse zone of the address block. To this method you can also add a whois query to the same address block.

UPDATE: example about www.speedtest.net:

$ dig a www.speedtest.net

www.speedtest.net.	289	IN	CNAME	www.speedtest.net.cdn.cloudflare.net.
www.speedtest.net.cdn.cloudflare.net. 289 IN A	104.18.202.232
www.speedtest.net.cdn.cloudflare.net. 289 IN A	104.18.203.232

Here I got real IP addresses of SpeedTest. Let's see resolved IP addresses:

$ dig -x 104.18.202.232

18.104.in-addr.arpa.	893	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

$ dig -x 104.18.203.232

18.104.in-addr.arpa.	757	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

Same pattern here: although IP addresses are not resolved back to any domain names, the reverse zones themselves have a SOA that clearly has a pattern: email & primary DNS from the cloudflare.com zone. To have the same pattern, you need to have access to the reverse DNS zone where the VPS is purchased. But even if you write a dummy SOA with the same data as cloudflare, the following checks will fail:

$ dig -x 104.18.203.232

18.104.in-addr.arpa.	757	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

It says which immediate upper zone is responsible for return addresses. Let's find the authoritative DNS for this zone:

$ dig ns 18.104.in-addr.arpa.

18.104.in-addr.arpa.	21600	IN	NS	cruz.ns.cloudflare.com.
18.104.in-addr.arpa.	21600	IN	NS	kevin.ns.cloudflare.com.

Now let's imagine that, for example, the address 8.8.8.8 (I took the public Google DNS example just as an example - you can use your own IP) is pretending to be a www.speedtest.net server, and GFW has a simple task - can the IP address 8.8.8.8 be a www.speedtest.net address (let's hypothetically imagine that Google has prescribed SOA or PTR records for 8.8.8.8 that also point to the cloudflare.com server to be similar to it as much as possible). A simple query to cloudlfare DNS on behalf of GFW will get a response:

$ dig @cruz.ns.cloudflare.com. -x 8.8.8.8

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @cruz.ns.cloudflare.com. -x 8.8.8.8
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14800
                                                         ^^^^^^^^^^^^^^^^
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
                                                  ^^^^^^^^^^^^^^^^^^^^^^^
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 20 (Not Authoritative)
^^^^^^^^^^^^^^^^^^^^^^^^^^
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.		IN	PTR

Now compare that to requesting an IP address from his responsibility:

$ dig @cruz.ns.cloudflare.com. -x 104.18.203.232
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @cruz.ns.cloudflare.com. -x 104.18.203.232
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35797
                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
                                                                  ^^^^^^^^^^^^^^^^
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;232.203.18.104.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
18.104.in-addr.arpa.	3600	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625505 10000 2400 604800 3600

Conclusion: no matter how X-Ray server pretends to be any server via SNI, there is a simple way to check its IP address via reverse resolving, and if it is not there - then through analyzing SOA records and queries to DNS responsible for the reverse zone.

If you look at the first post - it may very well be that the increased traffic triggers a check that was performed in a similar manner. This is just as an idea.

[neo2enigma]

Guys
Have you ever managed to check this video:
https://www.youtube.com/watch?v=By1DflMboUc&t=2801s
It describes why GFW is getting powerful because of TLS leak in Iranian panels!

[irgfw]

@neo2enigma Yes.
This is irrelevant. Those exposed panels are from old versions without SSL domains or panel path.
Our tests are without panels and just pure xray-core with ufw and the results were consistent with or without panels.

[salehMomtaz]

@Perlover
Hi, I did a very small test. I think your point is valid for MTN irancell. I think it depends on how much traffic they have on their networks and their technical capabilities to perform the task you explained. I couldn't get any number on internet traffic share of mci hamrah-e-avval and mtn irancell in Iran. But I am sure mci has a greater share of the whole country's internet traffic.
MTN plays the roll of private sector(MTN group, south Africa) . MCI is the government owned company. MCI is the dominant one.
These are tests I did with MahsaNG free config donation feature. You put your config in the site, it will share with people who can connect to it, analyse it based on their operator and ping they get.

Test 0
Not in the list, another person's account it was donated by.
dest and sni were zula.ir, irainan game site behind cloudflare. Server was banned after 18GB usage.

Test 1 wisdom-mahsa
self steal, reality on 8443, the real website on server on 443. dest was 127.0.0.1:443 and the sni was my own domain.

server was banned after 1TB. (A notable thing which I will mention later, Look at irancell users, they used till the last moments too. bar for MTN irancell gets taller when VPN was detected by MCI, although it was not, before the detection, meaning it was mci that detected the config. )

Test 2 zolan-mahsa
not self steal, the original reality way, SSL connection mimicking without a real domain. mimicking a popular website.
reality this time on 443, all ports closed but 443 and 80. 80 is occupied by nginx. nginx is running a server with self signed certs created by openssl for domain name google.com. nginx is configured for a website named google.com. sni of config is www.google.com.
dest 8443(occupied by nginx, not exposed to public)
IP was not banned, I couldn't pay for the server anymore, usage was 700GB before vps suspension.
nginx conf:

server {
	server_tokens off;
	server_name google.com *.google.com;
	listen 80;
	listen 8443 ssl;
 	listen [::]:80;
        listen [::]:8443 ssl;
	index index.html index.htm index.php index.nginx-debian.html;
	root /var/www/html/;
	ssl_protocols TLSv1.3;
	ssl_ciphers HIGH:!aNULL:!eNULL:!MD5:!DES:!RC4:!ADH:!SSLv3:!EXP:!PSK:!DSS;
	ssl_certificate /root/google.crt;
	ssl_certificate_key /root/google.key;
	if ($host !~* ^(.+\.)?google.com$ ){return 444;}
	if ($scheme ~* https) {set $safe 1;}
	if ($ssl_server_name !~* ^(.+\.)?google.com$ ) {set $safe "${safe}0"; }
	if ($safe = 10){return 444;}
	if ($request_uri ~ "(\"|'|`|~|,|:|--|;|%|\$|&&|\?\?|0x00|0X00|\||\|\{|\}|\[|\]|<|>|\.\.\.|\.\.\/|\/\/\/)"){set $hack 1;}
	error_page 400 402 403 500 501 502 503 504 =404 /404;
	proxy_intercept_errors on;
}

Do you notice that irancell users are gone after three days? but this did not happen when I used my own domain and a real site on my vps with real SSL in previous test.

Test 3 starandstripe configs
Like 2, but this time www.google.com is not the sni.
I resolved google.com with check host and host tracker for Iran. All gave one IP for the entire country. While when you use the all option, you see small countries like netherland will give you different ips.
Checked the subdomains, search.google.com client4.google.com .... each one of them resolved to different ips around the country.
For now, this one in 6 days, has passed 2.37TB. This server is very weak, I don't have money nor the ability to gain trial credits to buy powerful servers.

In order, doc, cli, fiber, search.

IP is banned by irancell now, and I wonder why it does not sync with the other operators.

Test 4 my personal
Config for my family and friends, passed nearly 700GB in 2 months, still works on MTN MCI and all other operators.
same nginx config as 1. but this time, reality on 443, nginx 80 and 8443(local) and a real website.
So, in conclusion, if they have the ability to detect suspicious connections, and then, perform that task on IP and sni of the connection, reality is detected. It shows irancell has that capability.
If you want to circumvent this one, a real domain and website on your vps is needed.
But remember Iran is very weak in internet, our whole network size is not comparable with China, US or Europe.
If you say no the traffic is low that is why it(my personal config) still works on irancell I have to say no, the trigger for irancell activated on second day, around 120GB.

[irgfw]

Great job on these tests—most of the results align with our findings. We’ll soon publish a comprehensive report on IRGFW, which will provide deeper insights and shed light on all the key areas related to IRGFW.

[salehMomtaz]

I think I made a mistake using google subdomains with self signed cert method which resulted the ip ban by irancell, not other operators.
I asked @amin4139 on twitter about his public configs.
He used fake domains(Iranian domestic domains like dotic.ir) with fastly cdn clean ips. He said he never faced ip bans. I remember when I tested his configs on irancell, they did work great.
Now what I mean by this, is that I should have used domestic domains. In one of the discussions or issues rprx said no it is absurd domestic domain as sni while ip is not domestic? but when that has worked for amin on tens of terabytes scale then we should use it.
And this, can be used for even tunneling.
Running reality with like rubika.ir as sni on an iranian vps. Now the ip is also domestic.

[salehMomtaz]

Update
Server has been running for 14 days, I don't understand why xray core restarts sometimes.

[Phoenix-999]

FYI
net4people/bbs#438

[Phoenix-999]

net4people/bbs#438 (comment)

[w0l4i]

look at this article https://irgfw.report/projects/project1/
by @irgfw about how irgfw in iran works @RPRX @mmmray

[irgfw]

If anyone is interested, we can discuss it here:

net4people/bbs#441

[salehMomtaz]

My test is finished. 5 configs were published. All were vless TCP reality xtls-rprx-vision. Four of them with Google subdomains, and one with a domestic domain. Server was active for a month from the 5th of December till the 5th of January.
Irancell blocked IP on the second day, around 100GB. There is a possibility of using reverse DNS mapping by Irancell for popular domains.
Other operators did not block the IP. It worked until suspension by the server provider.
Config with a domestic domain as sni was published on the 20th day, meaning IP was already banned by irancell.
So in conclusion, I will use "unpopular" domestic complicated domain next time I get to test reality.

[salehMomtaz]

https://edge01.82.ir.cdn.ir/
this is the domain i used for mahsa-ir, which passed 454GB.
I used some other popular domestic domains behind arvancloud cdn, for telegram fake-tls mtproxy, they work very well.
One of the things I want to add is, that for the first test, wisdom-mahsa, I used arvan to manage domain records. After that, I used only cloudflare. I also want to say that avoid using domain in address, if you are not running multiple servers behind a single domain, just put the IP in address field. As for self-steal you will enter it in sni field, preventing a DNS request to resolve domain in address field to ip.

[yuhan6665]

@realartin @irgfw thanks for your great reports! I finally have got some time to read about it ;)
Just have one comment, I see you mention the blocking is currently reduced so it may not be the best time to perform test. I just wonder if you guys have tried/tested XHTTP up and down split configuration with different routing like TCP UDP, IPv4 IPv6, CDN and see if that can improve the evasion of proxy servers

[irgfw]

@yuhan6665 Appreciate it.
Yes, We tested XHTTP, and it didn't encounter any blocking. However, when using Reality in a single stream, that specific stream gets blocked within four days. Other modes and streams using TLS work fine and remain operational.
However, some techniques can be used to make Reality work in Iran. We propose that the IRGFW employs a reverse DNS-mapping system to detect SNI-stealing proxy methods, such as Reality and ShadowTLSv3. Nevertheless, we have discovered certain methods to deceive this system, allowing the correct DNS to be presented to the firewall's buffer system.

You can read/discuss about the IRGFW Report 1 here:
net4people/bbs#441

[Phoenix-999]

FYI :
net4people/bbs#451
net4people/bbs#450

نسخه فارسی
ناسازگاری‌ها – بینش‌های جدید درباره سانسور اینترنت در ایران

reference, the original paper is also attached.
I(ra)nconsistencies: Novel Insights into IRAN’s Censorship

[Phoenix-999]

FYI:

https://gfw.report/publications/ndss25/en/

🚨We discovered Wallbleed, a vulnerability in the Great Firewall of China, allowing anyone leaks its memory. Since 2021, we reverse-engineered its logic, evaluated impact, and monitored patches. Wallbleed reveals censorship devices’ global privacy risks

[Phoenix-999]

FYI
Identifying VPN Servers through Graph-Represented Behaviors (ACM WWW 2024)

[seeker252]

Hello.
Today morning I thought, that I found some serious Reality volnurability. I hope to listen from you that I mistaken.
Look. Reality works as TLS 1.3 server and use SessionID for authenticate valid client connections. All requests from other clients transparently redirected to remote server by TCP. In TLS 1.3 SessionID must be random ir zero. Any TLS 1.3 server don't validate it. Ok. If third party (censor) change Reality client SessionID (with encrypted authentication data) in ClientHello with any 32 bit data for all TLS 1.3 Hellos to foreign IPs or IPs from grey lists, I think all legal (non-Reality) TLS 1.3 connections not be violated. We even can connect with our Reality VPS, but Reality server due to Session ID changed by third party will think about us as not valid Reality client and send our connection to remote server.
So censor no need to find Reality servers specially. He may mechanically change Session ID of TLS 1.3 ClientHello to any randon 32-bit value for some connections to some IPs and not violate any TLS 1.3 non-Reality connections. So HTTPs will work fine, but Reality don't.
Or I mistaken?

[salehMomtaz]

@seeker252
I want to add something to this. I saw this on mtn irancell network. it seems their firewall somehow blocks tls 1.3 connection to certain ips suspected of being a vpn server. I was thinking about this, and thought would be nice to have a look at previous discussions and found your comment. i guess at first this is a problem not by reality, but since i could not open the website on my vps neither, checked with openssl and curl and nc , this happens with tls 1.3 . with 1.2 everything is okay, http1.1 or 2 both works if tls version is set to 1.2.
I fear that doing this will result in vulnerability in other isps in cost of working on mtn irancell.
would appreciate a response from you @Phoenix-999
instead of using reality when i use tls with tls max version 1.2 in configuration there is no problem at all. I found another open issue net4people/bbs#438 and @RPRX has yet to address this.
some special charcteristics of reality is probably invoking some kind of trigger. the mechanism maybe has some collateral damages, and maybe they just decided to block tls 1.3 for that suspicious ip( since they know reality is based on tls 1.3)

[salehMomtaz]

net4people/bbs#438
@fodhelper

[Phoenix-999]

@seeker252 & @salehMomtaz

Sorry in advance for the wall of text. 😅 I promise there's a point to it. I've spent the past few weeks testing Reality across different Iranian ISPs, VPS providers, domains, and all sorts of network conditions. Every time I tried to shorten my notes, I ended up leaving out something that seemed important. I definitely don't claim to have all the answers, and some of the ideas below are just hypotheses based on what I've observed. If I'm completely off, hopefully someone can point me in the right direction. If not, maybe these observations help connect a few dots and move the discussion forward.

---

I don't know whether this is actually a Reality vulnerability, but I'd like to share some observations from field testing that may be relevant to this discussion.

Over the past three weeks, I have been continuously testing Reality across multiple Iranian ISPs under different network conditions. The testing included different VPS providers, fresh and older VPS IP addresses, various camouflage domains and SNI hostnames, and different traffic patterns ranging from light personal use to sustained multi-client activity.

The first thing that stood out is that the censorship environment today is noticeably different from what I observed roughly two months ago. Overall, filtering appears to be less aggressive than before, and several circumvention protocols, including Reality, have become usable again under the right conditions.

Another interesting observation is that different ISPs do not behave identically. While they appear to share the same overall filtering objectives, their behavior differs in terms of sensitivity, timing, and consistency. The exact same Reality configuration can work reliably on one ISP while performing poorly on another. Some providers appear to trust newly deployed endpoints for longer periods, while others seem to classify them much more quickly. This suggests that ISPs may maintain different reputation databases, apply different classification thresholds, or deploy filtering updates on different schedules. Whether those systems are completely independent or simply implement a common policy differently is difficult to determine from external observation alone.

Across all of my testing, the Reality configuration itself has had surprisingly little influence on the success rate compared to the apparent reputation of the endpoint being presented to the network.

Based on my observations, the factors that appear to have the greatest influence are roughly the following, listed in order of importance:

1. Destination VPS IP reputation. Freshly allocated IP addresses consistently perform better than IPs that have been in use for longer periods or appear to have accumulated a poor reputation.

2. SNI hostname or subdomain reputation. The specific hostname presented during the TLS handshake often seems more important than the Reality configuration itself. Hostnames with a good reputation consistently produce higher connection success rates.

3. Camouflage domain reputation. Well-established, highly trusted domains that are widely accessed by legitimate users generally perform better than obscure or infrequently used domains.

4. VPS provider or ASN reputation. Although this requires more validation, some hosting providers appear to experience classification sooner than others, suggesting that the surrounding network may also contribute to the overall reputation of an endpoint.

5. Connection behavior over time. Sustained high traffic volumes, unusually high connection rates, large numbers of simultaneous clients, or sudden spikes in activity may gradually influence how an endpoint is classified. This observation is still anecdotal, but it has appeared consistently enough during testing to deserve further investigation.

When these factors are favorable, Reality generally works very well without requiring any changes to its configuration. Conversely, once one or more of these reputation signals begins to deteriorate, connection reliability drops significantly even though the Reality configuration itself remains identical.

This leads me to think that protocol identification alone may not determine whether a connection succeeds or fails. Instead, the filtering system may evaluate multiple independent characteristics and combine them into an overall classification before deciding how the connection should be handled.

---

⚠️‼️ Another observation may also be relevant.

If I establish a VPN connection and initiate a WhatsApp, Telegram, or FaceTime video call, then disconnect the VPN after the media session has already been established, the video stream frequently continues without interruption while almost all new application traffic immediately stops working. Messages remain stuck on "Connecting," new requests fail, yet the existing media session continues normally. Several other users have independently reproduced the same behavior across different Iranian ISPs.

Although this does not identify the filtering mechanism, it suggests that the most intensive inspection may occur during connection establishment rather than throughout the lifetime of the connection. Once a flow has been accepted and entered into the state table, subsequent packets may receive considerably less scrutiny than the initial TCP connection, TLS handshake, and first application packets. From an engineering perspective, this would also be a practical design, since continuously performing deep packet inspection on every packet would require substantially more processing resources.

If that hypothesis is correct, it could also explain why Reality is particularly sensitive to anything that happens during the TLS 1.3 ClientHello. Reality performs its authentication during that stage, so any classification, manipulation, or policy decision made before authentication completes can prevent the encrypted session from being established successfully.

Regarding the Session ID hypothesis raised above, if a censor is capable of modifying the TLS 1.3 ClientHello Session ID without disrupting ordinary TLS traffic, then Reality authentication could indeed fail while conventional HTTPS connections continue functioning normally. From a protocol perspective, this appears technically plausible. However, there is currently no evidence demonstrating that Session ID rewriting is actually occurring, so it should be treated as one possible hypothesis rather than a conclusion.

It is equally important to consider that Session ID modification is only one possible explanation. Similar symptoms could occur without modifying any TLS fields at all. A filtering system could simply classify the connection during the first round trip and then selectively drop packets, inject TCP reset packets, delay forwarding, silently discard traffic, or terminate the connection based on an internal policy decision.

The Session ID may not even be the primary target. Instead, the filtering system could be evaluating a combination of observable characteristics during the initial connection, including:

• TCP/IP fingerprinting
• JA3 or JA4 style TLS fingerprinting
• TLS ClientHello structure and extension ordering
• TLS 1.3 handshake characteristics
• ALPN negotiation
• Destination VPS IP reputation
• SNI hostname or subdomain reputation
• Camouflage domain reputation
• VPS provider or ASN reputation
• Connection timing and behavioral patterns
• Historical reputation accumulated over time
• Selective modification of specific handshake fields

Active probing should also be considered. Some censorship systems classify a connection as suspicious and later establish their own connections to determine whether the endpoint is hosting a circumvention protocol. Since Reality was specifically designed to resist active probing, this is another mechanism that deserves consideration.

Some publicly reported observations also appear consistent with this broader interpretation. For example, users on MTN Irancell have reported situations where forcing TLS 1.2 restores connectivity while TLS 1.3 fails for the same VPS, even when accessing ordinary HTTPS services. Although these reports do not identify the underlying cause, they suggest that characteristics of the TLS 1.3 handshake itself may influence the filtering decision independently of Reality.

Another pattern that repeatedly appeared during testing is that reputation seems to evolve over time rather than remaining static. Newly allocated VPS IP addresses often work immediately without any configuration changes, yet the same servers may gradually become less reliable after days or weeks of use. Migrating the identical Reality configuration to a fresh IP frequently restores connectivity. A similar pattern may also apply to camouflage domains and SNI hostnames if they become associated with a large number of Reality deployments. While these observations remain anecdotal and require more systematic validation, they are consistent with a dynamic reputation system rather than a purely static blocklist.

Taken together, these observations suggest that the censorship infrastructure may no longer rely on a single detection technique. Instead, it appears to perform an early, multi-factor classification during connection establishment before encrypted application data begins flowing. Rather than making a decision based on one field within the TLS handshake, the system may evaluate protocol characteristics, TLS fingerprints, TCP/IP fingerprints, endpoint reputation, historical behavior, traffic patterns, and ISP-specific policies before determining how a connection should be handled.

Whether Reality failures are ultimately caused by Session ID modification, TLS fingerprinting, endpoint reputation, behavioral analysis, active probing, selective packet manipulation, or some combination of these mechanisms remains an open technical question.

The only reliable way to distinguish between these possibilities is through synchronized packet captures collected simultaneously on both the client and the Reality server while reproducing the issue. Comparing the TCP metadata, sequence numbers, timestamps, TLS records, and the complete ClientHello byte-for-byte would determine whether handshake fields are actually being modified in transit or whether the connection is simply being classified and acted upon without altering the TLS exchange.

If anyone else has observed similar behavior, especially across different ISPs or with packet captures to support those observations, I would be very interested in comparing results. The more independent data points we collect, the better our chances of understanding what is actually happening.

[Phoenix-999]

@salehMomtaz & @seeker252

I also wanted to share this video because I think it's well worth watching.

It does a great job of explaining, in a simple and easy-to-follow way, which companies are involved in Iran's internet censorship ecosystem, what their roles are, and how they contribute to the country's filtering infrastructure.

What makes this especially concerning is that most people have never even heard of these companies. They operate largely behind the scenes, receive very little public attention, and their role in building and maintaining the censorship system often goes unnoticed.

These are names that deserve to be known, remembered, and discussed.

In my opinion, the scale and sophistication of Iran's internet censorship infrastructure is one of the country's least understood issues. The technical and organizational complexity behind it is enormous, yet very little of it is visible to the public. Once you start looking into how this ecosystem is built, you realize it's far more extensive than most people imagine.

If you're interested in understanding the bigger picture behind internet filtering in Iran, I think this video provides a valuable overview.

---

01.mp4

---

02.mp4