bbs
bbs copied to clipboard
net4people
Large scale blocking of Reality and (relayed) WS + TLS protocols in Iran (MCCI; AS43358)
Starting a few days ago, there have been widespread reports that MCCI is blocking Reality-based VPNs in a matter of hours and with low traffic. Additionally, WS + TLS VPNs that take advantage of CDNs (e.g., Cloudflare) are barely working. Even if you use a domestic (Iranian) CDN (e.g., Arvan Cloud), which generally has access to a less censored Internet, they almost don't work anymore.
Here are some of my observations:
- According to Netreach, connection to previously uncensored websites is unchanged. This probably means the new system is pretty good at detecting these protocols, not just sending blind noise to disrupt all connections.
- The popular SNI used in Reality connections among Iranian users,
speedtest.net,is not working well anymore. However, some start working well again by changing to new SNIs. - You can still use Arvan Cloud CDN with WS + TLS on Irancell, another giant provider. This probably means the reason it stopped working on MCCI has something to do with the connection between the user's device and the CDN's servers. Worth noting that direct WS + TLS connections have been almost unusable for the last 6 months.
So, what are the next steps now? When this new system gets used on all the main providers in Iran, I don't think there will be much more options left. Using a domestic relay (whether a CDN or server) was always deemed the last resort to escape censorship.
Additionally, WS + TLS VPNs that take advantage of CDNs (e.g., Cloudflare) are barely working
I am not sure if it still applies, but I managed with this scheme last week:
- do not use TLS, but plain HTTP. then, use vmess inside ws for privacy
- point clients to specific IPv4 addresses, not the domain itself. there is a large variance in which IP addresses work and which don't. . anything starting with
104.is broken, but cloudflare typically gives you two A records for their proxy - configure cloudflare to have a wildcard (
*.foo.example.com), and randomize host header in client config (a.foo.example.com, etc)
also, plain tcp+vmess continues to work for as long as you can afford to switch IP regularly.
i want to try ipv6-only proxies next
MCI is blocking REALITY servers in Iran #2451
Just wanted to shed some more light on this situation. Fired up a couple of brand-new VPS servers with clean IPs, and just to be extra safe, I threw in a CDN certificate for good measure. And to top it off, I went ahead and blocked all IR domains and IPs directly on the server.
No big traffic spikes here, just a handful of small video files being sent back and forth for a legit speed test. And to keep things interesting, I've got the VPN running on a couple of devices as well.
Rest assured, all the devices are locked down tight. Our client apps and software are up-to-date and set up perfectly. I've only used "Reality" on 443 port and I've got us covered with whitelisted SNI, and I've gone the extra mile to implement every possible security measure to the best of my understanding.
Out of the three VPS instances, one got the Blocked within just 4 hours, while the other two managed to hold on for about a day before they were also blocked.
The second and third VPS instances started acting up with erratic and unusually high ping, causing a significant slowdown in speed. After a few hours of this instability, they eventually ended up completely blocked. It's starting to look like a potential DDoS attack on the servers.
I hope the information above sheds some light on the subject.
Problems:
-
Blocking of Reality-based VPNs: There are reports of MCCI (Iranian ISP) blocking Reality-based VPNs within a short timeframe and with low traffic.
-
WS + TLS VPNs with CDNs: WS + TLS VPNs utilizing CDNs (like Cloudflare) are experiencing limited functionality and are barely working.
-
Ineffectiveness of Domestic CDNs: Even using domestic Iranian CDNs (e.g., Arvan Cloud) is not providing reliable access to a less censored internet.
-
Unchanged Connection to Uncensored Websites: The new blocking system seems to be able to detect specific protocols rather than causing general disruption to all connections. Access to previously uncensored websites remains unaffected.
-
SNI Detection Issues: The SNI (Server Name Indication) used in Reality connections is not working effectively anymore. Switching to new SNIs has had mixed success.
-
Direct WS + TLS Connections Unusable: Direct WS + TLS connections have been nearly unusable for the past 6 months.
-
Potential DDoS Attack: Some VPS instances experienced erratic behavior and high ping, leading to slowdowns and eventual blocking. This behavior could indicate a potential Distributed Denial of Service (DDoS) attack.
Solutions and Suggestions:
-
Use Plain HTTP and VMess Inside WS: One user suggests using plain HTTP instead of TLS, and then utilizing VMess inside WebSocket (WS) for privacy. This approach may help in bypassing the blocking mechanisms.
-
Point to Specific IPv4 Addresses: Instead of relying on domain names, pointing clients to specific IPv4 addresses can potentially bypass the blocking. Cloudflare's proxy provides multiple A records that might have varying levels of effectiveness.
-
Randomize Host Headers: Configuring Cloudflare with a wildcard (*.foo.example.com) and randomizing the host header in client configurations can help avoid detection.
-
Consider IPv6-Only Proxies: There's a suggestion to try using IPv6-only proxies as a potential solution.
-
Whitelisted SNI: Implementing whitelisted SNI (Server Name Indication) can potentially help in evading detection and blocking.
Problems:
- Blocking of Reality-based VPNs: There are reports of MCCI (Iranian ISP) blocking Reality-based VPNs within a short timeframe and with low traffic.
- WS + TLS VPNs with CDNs: WS + TLS VPNs utilizing CDNs (like Cloudflare) are experiencing limited functionality and are barely working.
- Ineffectiveness of Domestic CDNs: Even using domestic Iranian CDNs (e.g., Arvan Cloud) is not providing reliable access to a less censored internet.
- Unchanged Connection to Uncensored Websites: The new blocking system seems to be able to detect specific protocols rather than causing general disruption to all connections. Access to previously uncensored websites remains unaffected.
- SNI Detection Issues: The SNI (Server Name Indication) used in Reality connections is not working effectively anymore. Switching to new SNIs has had mixed success.
- Direct WS + TLS Connections Unusable: Direct WS + TLS connections have been nearly unusable for the past 6 months.
- Potential DDoS Attack: Some VPS instances experienced erratic behavior and high ping, leading to slowdowns and eventual blocking. This behavior could indicate a potential Distributed Denial of Service (DDoS) attack.
Solutions and Suggestions:
- Use Plain HTTP and VMess Inside WS: One user suggests using plain HTTP instead of TLS, and then utilizing VMess inside WebSocket (WS) for privacy. This approach may help in bypassing the blocking mechanisms.
- Point to Specific IPv4 Addresses: Instead of relying on domain names, pointing clients to specific IPv4 addresses can potentially bypass the blocking. Cloudflare's proxy provides multiple A records that might have varying levels of effectiveness.
- Randomize Host Headers: Configuring Cloudflare with a wildcard (*.foo.example.com) and randomizing the host header in client configurations can help avoid detection.
- Consider IPv6-Only Proxies: There's a suggestion to try using IPv6-only proxies as a potential solution.
- Whitelisted SNI: Implementing whitelisted SNI (Server Name Indication) can potentially help in evading detection and blocking.
Regarding the solutions and suggestions:
- Plain HTTP and VMess inside WS doesn't work for me at all. (Both on MCCI and MTN)
- Using specific Cloudflare IPs has mixed results for MTN (it seems the GFW eases or aggravates connections) but almost doesn't work at all on MCI.
- I have yet to try this one.
- As far as I know, IPv6 only works for MTN thus IPv6-based solutions won't work on MCCI where new solutions are most needed.
- AFAIK,
speedtest.netis one of the whitelisted SNIs in Iran for almost all providers. I suppose there's more to this new detection system than just using a whitelisted SNI.
However, One possible solution could be choosing an SNI that's hosted on your VPS provider. So if you have a VPS from Google Cloud, you must choose an SNI from the whitelisted websites hosted on GCP. (e.g., gmail.com)
Just an Update
These serverless methods continue to function with MCI. ✔️ Workers + Fragment ✔️ Warp app by changing endpoints IP
This is not a protocol blocking. MCI and TCI just limit the DL/UL speed after some high-traffic usage from the server. and after 2-3 days they block the IP address based on the traffic usage. It is the upgraded Iran's GFW.
This is not a protocol blocking. MCI and TCI just limit the DL/UL speed after some high-traffic usage from the server. and after 2-3 days they block the IP address based on the traffic usage. It is the upgraded Iran's GFW.
If they were arbitrarily limiting the speed to IPs that see high-traffic, it should have severely impacted non-VPN servers (i.e., normal websites) too. My observation (and inspection with Netreach) shows that normal websites are almost unaffected by MCCI.
Update - Thu 17 Aug - 13:50
Multiple reports from various locations across Iran indicate a common issue: encountering notable throttling, severe disruption, and substantial fluctuations on different ISPs. This scenario strongly suggests the possibility of a coordinated attack, potentially orchestrated by MCI.
We speculate that the recent events and peculiar behavior exhibited by ISPs in Iran could be indicative of some form of preparation or demonstration of power, potentially in anticipation of the upcoming commemoration of Mahsa Amini and other brave individuals who tragically killed and murdered during last year's uprising against the dictatorial regime.
As a wise man once said: "We can never forget that no matter how much it hurts, how dark it gets, or how far we fall, we are never out of the fight." ✌🏾
This is not a protocol blocking. MCI and TCI just limit the DL/UL speed after some high-traffic usage from the server. and after 2-3 days they block the IP address based on the traffic usage. It is the upgraded Iran's GFW.
If they were arbitrarily limiting the speed to IPs that see high-traffic, it should have severely impacted non-VPN servers (i.e., normal websites) too. My observation (and inspection with Netreach) shows that normal websites are almost unaffected by MCCI.
They are not affected because they are whitelisted. You can test it now. Buy a new VPS and setup s simple nginx webserver. And then upload some heavy files on that from MCI after 1Gb or 2Gb data the DL/UL speed will be limited to 0.1 mb/s. This new behavior is for MCI and TCI ISPs. They just 'Graylist' the IP address unless it's listed as a whitelisted IP address from a certain database or timestap snapshot!
Recent reports have surfaced, indicating that specific individuals have received warning messages from domestic VPS providers. These notifications inform them that their VPS IP addresses have been blocked due to the detection of VPN or proxy services on their servers. Additionally, they are advised not to generate any traffic for the next 72 hours.
Here some an example of warning messages
Has anyone else encountered the same problem?
Recent reports have surfaced, indicating that specific individuals have received warning messages from domestic VPS providers. These notifications inform them that their VPS IP addresses have been blocked due to the detection of VPN or proxy services on their servers. Additionally, they are advised not to generate any traffic for the next 72 hours.
Here some an example of warning messages
Has anyone else encountered the same problem?
Yes this is common among Iranian VPS providers. You should buy from websites that dont have limitations for tunneling and proxy servers but the traffic is expensive as hell... (1Gb=500Tomans and more...) Also don't use iptalbes or nftables or common tunneling solutions. They will be detected easily.
Yes this is common among Iranian VPS providers. You should buy from websites that dont have limitations for tunneling and proxy servers but the traffic is expensive as hell... (1Gb=500Tomans and more...) Also don't use iptalbes or nftables or common tunneling solutions. They will be detected easily.
I'm working to establish a connection between these incidents and coincidences to ascertain whether they are linked to the coordinated attack by MCI. This is prompted by the fact that numerous individuals have reported receiving the same kind of messages over the last 2 to 3 days.
OR it's a valid point that we might be experiencing heightened paranoia and caution as a result of the simultaneous occurrence of multiple events!!!
They are not affected because they are whitelisted. You can test it now. Buy a new VPS and setup s simple nginx webserver. And then upload some heavy files on that from MCI after 1Gb or 2Gb data the DL/UL speed will be limited to 0.1 mb/s.
I would like to see this test behind cloudflare CDN. in order for this censorship method to be effective with cloudflare, one would have to implement bandwidth limits both per destination IP and SNI. or is cloudflare currently just collateral damage?
asked another way: is bandwidth limiting done individually per-IP and per-SNI, or per tuple of (IP, SNI)? In the latter case, randomizing subdomains in SNI would help (which can be done even on cloudflare)
same question about the whitelist. do we think the whitelist is about IPs, SNI or the combination of both
Plain HTTP and VMess inside WS doesn't work for me at all. (Both on MCCI and MTN)
I believe this has stopped working on exactly Aug 16 13:40 UTC, or at least that is the occurrence where I see a large bandwidth drop.
interesting: a proxy of mine where the outbound bandwidth is throttled to 7 MiB/s (intentionally, to control cost) in total continues to work fine at the same bandwidth usage. I think this corroborates @hawshemi's statements
This is not a protocol blocking. MCI and TCI just limit the DL/UL speed after some high-traffic usage from the server. and after 2-3 days they block the IP address based on the traffic usage. It is the upgraded Iran's GFW.
If they were arbitrarily limiting the speed to IPs that see high-traffic, it should have severely impacted non-VPN servers (i.e., normal websites) too. My observation (and inspection with Netreach) shows that normal websites are almost unaffected by MCCI.
They are not affected because they are whitelisted. You can test it now. Buy a new VPS and setup s simple nginx webserver. And then upload some heavy files on that from MCI after 1Gb or 2Gb data the DL/UL speed will be limited to 0.1 mb/s. This new behavior is for MCI and TCI ISPs. They just 'Graylist' the IP address unless it's listed as a whitelisted IP address from a certain database or timestap snapshot!
This is super interesting. However there are still some questions:
- If they are whitelisting websites based on their IPs, this means that many IPs are now "clean." As almost all websites use major providers' CDNs, this would mean that you can find a lot of "clean" IPs on big providers such as Azure, GCP, and AWS? I'm not sure, but it'd also mean that you could use Cloudflare as a reverse proxy for your Reality server and put a white-listed website that also uses Cloudflare as the SNI.
- The other one is I've seen some configs that had stopped working with
[speedtest.net](http://speedtest.net/)SNI but started working again with[www.theverge.com](http://www.theverge.com/). How does that fit into your theory that they are only limiting IPs with high traffic?
The other one is I've seen some configs that had stopped working with speedtest.net SNI but started working again with www.theverge.com. How does that fit into your theory that they are only limiting IPs with high traffic?
It could fit if the bandwidth throttling happens on a tuple/combination of (IP, SNI). more tests are needed
The other one is I've seen some configs that had stopped working with speedtest.net SNI but started working again with www.theverge.com. How does that fit into your theory that they are only limiting IPs with high traffic?
It could fit if the bandwidth throttling happens on a tuple/combination of
(IP, SNI). more tests are needed
I won't rule this out, but it's highly unlikely imo.
I've been experimenting with reality, with around 10 clients over a few weeks. Around the same time that there were power outages in Tehran, I noticed the IP of the server was suddenly blocked across all providers. I switched a few of them to a new server, and that IP was also blocked within a few hours. I migrated one user to another server on a very little-known VPS provider and that was blocked after about 2 hours. The user didn't even pull over 800KB/s, and didn't transfer more than a few hundred MB in that time window. I didn't change the keys or SNI during that 24 hour window of all these events. There are a few possible methods of filtering that I can think of with this, but I'm not sure yet.
Could it be that they are monitoring all SNIs that seem to have a high amount of traffic, collecting the destination IPs, then batch resolving those SNIs to find real IPs, then blocking the non-real ones?
The fact that blocking or throttling doesn't happen immediately tells me there's a window where data is collected, and batch operations or waves of blocking/throttling occurs.
When throttling is happening, it's likely they observe connection counts for the IP+SNI tuple, then take that IP and throw it in a general block/throttle list. It's very unlikely to be actively done in realtime, as that kind of detection would be CPU expensive.
Keep in mind that this new mechanism that's being observed applies simultaneously on all downstream civilian internet providers. Which means that the system was either deployed and enabled at all operator exchanges or datacenters at the same time, or that the new system is operating at a higher aggregation point in the national network. I personally haven't seen it like this before, except for the basic things like the DNS manipulation system.
An idea that may both prevent the IP+SNI tuple from being detected in the first place, and also to put a lot of load on the filtering systems, is to perhaps fragment the TLS header of REALITY??? Because a filtering system would have to actively store a 4tuple (src+dest IP+port) and wait a really long time before it can build the full SNI in memory. The filtering system would have to forget the 4tuple and partial SNI after a small time, or run the risk of running out of memory. (if the number of connections doing this is high)
Could it be that they are monitoring all SNIs that seem to have a high amount of traffic, collecting the destination IPs, then batch resolving those SNIs to find real IPs, then blocking the non-real ones?
the idea that ISPs maintain table of SNI to allowed IPs for the top N sites has been widely discussed in a lot of older threads from around this year (in this BBS but also in xray-core issuetracker). we can assume it exists, and it would still allow for the possibility that switching SNI from speedtest.net to theverge.com unblocks traffic. because theverge.com is simply not a popular enough domain to be in that table, so its IP is not validated at all.
it doesn't explain though why you can switch IPs and have a time window where the proxy works. assuming you do not switch SNI, and your old proxy has been banned via the above mechanism (ie. SNI-based) and not something else, the new IP should never work
therefore it seems more likely to me that the new mechanism you are interacting with is not SNI-based at all
This is super interesting. However there are still some questions:
- If they are whitelisting websites based on their IPs, this means that many IPs are now "clean." As almost all websites use major providers' CDNs, this would mean that you can find a lot of "clean" IPs on big providers such as Azure, GCP, and AWS? I'm not sure, but it'd also mean that you could use Cloudflare as a reverse proxy for your Reality server and put a white-listed website that also uses Cloudflare as the SNI.
- The other one is I've seen some configs that had stopped working with
[speedtest.net](http://speedtest.net/)SNI but started working again with[www.theverge.com](http://www.theverge.com/). How does that fit into your theory that they are only limiting IPs with high traffic?
I don't know if you are currently in Iran and testing these methods but in theory, "yes" we can use those clean IPs. but currently, Iran's GFW just throttles the IPs from Cloudflare (UL speed) in the first place! so for most of the operators the idea of "CF clean IP" is almost dead (but not completely for "some" ISPs).
As of the top VPS providers:
- GCP is completely blocked due to sanctions (google blocked the IP addresses from Iran)
- Azure has clean IPs (in the EU zone) and can be used as v2ray/xray/hysteria/... protocols. But from 1 week ago (after the GFW upgrades), the IP address will be throttled after using REALITY on MCI/TCI (even with all the security measures)
- AWS has "some" clean IPs but you should test and change IP for like an hour or two to get a "semi-clean" IP which connects to "some" ISPs and is blocked at other ISPs!
For the SNI changing, it could be possible that the GFW just observes and save the IP/SNI/FP dict. because many of my servers are just blocked by GFW but after changing the FP (fingerprint) it connects perfectly! this theory is also valid... more tests are needed.
Could it be that they are monitoring all SNIs that seem to have a high amount of traffic, collecting the destination IPs, then batch resolving those SNIs to find real IPs, then blocking the non-real ones?
the idea that ISPs maintain table of SNI to allowed IPs for the top N sites has been widely discussed in a lot of older threads from around this year (in this BBS but also in xray-core issuetracker). we can assume it exists, and it would still allow for the possibility that switching SNI from
speedtest.nettotheverge.comunblocks traffic. becausetheverge.comis simply not a popular enough domain to be in that table, so its IP is not validated at all.it doesn't explain though why you can switch IPs and have a time window where the proxy works. assuming you do not switch SNI, and your old proxy has been banned via the above mechanism (ie. SNI-based) and not something else, the new IP should never work
therefore it seems more likely to me that the new mechanism you are interacting with is not SNI-based at all
I don't think it's just one change. It has changed from a week ago with two or more mechanics updates. One of them is blocking the IP address of the server based on SNI. One of them is simply just the amount of traffic on the server. I just changed the SNI from www.speedtest.net to www.theverge.com and it is working ok now. (but no one knows for how long). The other thing is just the combination of the server IP address and SNI and Fingerprint.
So, what are the next steps now? When this new system gets used on all the main providers in Iran, I don't think there will be much more options left. Using a domestic relay (whether a CDN or server) was always deemed the last resort to escape censorship.
At the end of my summary of methods, I listed some "last resort" methods. You might try some of those. But there's a general principle here. If a method ever becomes too popular, it gets blocked. You have to be continually looking for something new and different.
I don't know if you are currently in Iran and testing these methods but in theory, "yes" we can use those clean IPs. but currently, Iran's GFW just throttles the IPs from Cloudflare (UL speed) in the first place! so for most of the operators the idea of "CF clean IP" is almost dead (but not completely for "some" ISPs).
As of the top VPS providers:
- GCP is completely blocked due to sanctions (google blocked the IP addresses from Iran)
- Azure has clean IPs (in the EU zone) and can be used as v2ray/xray/hysteria/... protocols. But from 1 week ago (after the GFW upgrades), the IP address will be throttled after using REALITY on MCI/TCI (even with all the security measures)
- AWS has "some" clean IPs but you should test and change IP for like an hour or two to get a "semi-clean" IP which connects to "some" ISPs and is blocked at other ISPs!
For the SNI changing, it could be possible that the GFW just observes and save the IP/SNI/FP dict. because many of my servers are just blocked by GFW but after changing the FP (fingerprint) it connects perfectly! this theory is also valid... more tests are needed.
Thanks for your reply.
Regarding GCP, you're unfortunately right. It's a shame for Google honestly.
For Cloudflare there are dozens of websites that are on Cloudflare and you can access them fine with MCI (e.g., discord.com) but if you use discord.com as your address in a WS + TLS config behind Cloudflare CDN, the download speed is almost zero too. So this means there's some form of recognition of normal browsing from WS + TLS for the filtering system.
What I'm looking for is to use Cloudflare as a reverse proxy for a Reality VPN server. You would use discord.com as the SNI and Cloudflare's IP for the address. Theoretically, If they are unable to detect Reality's traffic characteristics, this should work. (I'll try to test this out and report back)
An interesting observation:
If you find "clean" IPs for Cloudflare, WS + TLS configs work somewhat decently for MCCI. However, WS + TLS behind a domestic CDN (e.g., Arvan) almost doesn't work. Additionally, WS + TLS behind Arvan works perfectly for MTN.
Since they are not catching VPN connections to some clean CF IPs, it tells me that it's not about traffic characteristics, and it's all about IPs. However, Why doesn't it work with Arvan then?
I really can't make sense of what's happening here.
-
Blocking Behavior:
- MCI and TCI ISPs in Iran throttle DL/UL speeds after high-traffic usage.
- IPs are blocked after 2-3 days of heavy traffic.
- Non-VPN servers (normal websites) are not affected due to whitelisting.
-
Graylisting and IP Whitelisting:
- IPs are 'graylisted' unless whitelisted in a specific database.
- Blocking occurs in waves or batch operations after data collection.
-
Data Collection and Blocking Mechanism:
- Monitoring SNIs with high traffic to collect destination IPs.
- Batch resolving SNIs to find real IPs for blocking.
- Throttling based on observed connection counts for IP+SNI tuple.
-
Mitigation Strategies:
- Fragmenting TLS header to hinder SNI detection and increase load on filters.
- Changing IP and fingerprint to bypass GFW blocking.
-
Cloud Service Providers (CSPs) Status:
- GCP blocked due to sanctions; IPs from Google are inaccessible.
- Azure throttles IPs after using REALITY on MCI/TCI.
- AWS IPs work with varied success across ISPs; frequent FP changes help.
- Non-VPN servers (normal websites) are not affected due to whitelisting.
Some users reported even with a simple nginx webserver and uploading to it, it will be limited after 2-3gb of traffic.
What I'm looking for is to use Cloudflare as a reverse proxy for a Reality VPN server. You would use discord.com as the SNI and Cloudflare's IP for the address.
cloudflare does not allow for domain fronting so it won't happen. you can use arbitrary cloudflare IP to connect to any website, but stealing somebody else's SNI and connecting to your own server won't work
An idea that may both prevent the IP+SNI tuple from being detected in the first place, and also to put a lot of load on the filtering systems, is to perhaps fragment the TLS header of REALITY??? Because a filtering system would have to actively store a 4tuple (src+dest IP+port) and wait a really long time before it can build the full SNI in memory. The filtering system would have to forget the 4tuple and partial SNI after a small time, or run the risk of running out of memory. (if the number of connections doing this is high)
Combination of XTLS and Fragment does not work
[Warning] [328153325] app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: XTLS only supports TLS and REALITY directly for now.
I also tested on a working VLESS + TCP + Reality instance, When I activate the fragments for Reality outbound on the client, It fails to finish SSL handshake.
* Uses proxy env variable all_proxy == 'socks5h://127.0.0.1:10801'
* Trying 127.0.0.1:10801...
* Connected to 127.0.0.1 (127.0.0.1) port 10801 (#0)
* SOCKS5 connect to ifconfig.io:443 (remotely resolved)
* SOCKS5 request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 10801 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ifconfig.io:443
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ifconfig.io:443
I also tried setting sockopt.dialerProxy, Xray-core does take it into account but then setting it into an invalid value also works...
- Non-VPN servers (normal websites) are not affected due to whitelisting.
Some users reported even with a simple nginx webserver and uploading to it, it will be limited after 2-3gb of traffic.
Meanwhile someone reported that tunnelling 30G data per day through SSH does not result in a block. https://github.com/XTLS/Xray-core/issues/2451#issuecomment-1684935929. Does this incident mainly affect TLS stuff?
Okay. Did some more experiments and here are the results:
1- You need a "clean" IP for your WS + TLS config to work even behind Arvan CDN for MCI. For some IPs, you could perfectly use Arvan CDN and MCI but for some others, it just doesn't work at all. Additionally, A lot of those IPs that don't work for MCI, work perfectly with MTN.
I have no idea how this could happen other than Arvan collaborating with the filtering system, which seems unlikely honestly. So this means that Arvan's edge servers would decline to fulfill a proxy request if it's coming from MCI AND the IP is grey-listed but would serve MTN requests regardless? Moreover, one of my IPs that doesn't work with MCI + Arvan CDN is working perfectly with MCI + Cloudflare CDN.
I'd love to know what you guys think about this.
2- For those IPs that MCI + Arvan CDN work, you could have perfect direct WS + TLS connections too. (Vless, Vmess, Trojan). But for the IPs that MCI + Arvan CDN didn't work, direct WS + TLS connections don't work either.
3- I also toyed with using Reality with some SNIs that were in the same ASN as my VPN server but they didn't work. There still doesn't seem to be a systematic "method" to choose an SNI that makes it indistinguishable from the "real" traffic. A couple of SNIs work nicely for MCI, but nobody knows why they work and how detectable they are.