Shutdowns, intensified blocking in Iran since 2022-09-21

[wkrp]

There are reports of shutdowns in some mobile ISPs in Iran since about 2022-09-21 16:00 UTC (20:30 Tehran IRDT, about 8 hours ago). I don't know much technical detail yet.

IODA doesn't show a major drop in the country as a whole:
https://ioda.inetintel.cc.gatech.edu/country/IR?from=1663135200&until=1663826399

But you can see an effect in certain ISPs, like IranCell here:
https://ioda.inetintel.cc.gatech.edu/asn/44244?from=1663135200&until=1663826399

It may be a good idea to review #102, lessons from the January 2022 shutdown in Kazakhstan, and for example do some port scans to see if there are holes in the shutdown.

If you experience a shutdown and are able to get online for even a little while, Access Now has a form to report your experience:
https://www.accessnow.org/keepiton/#take-action
https://forms.gle/pUh6EPwwtkD65BDY6

Some Twitter posts:

https://twitter.com/OliverLinow/status/1572698570498920449 (archive)

#Iran Internet Black Out - 21.09.2022
14:00 UTC: Instagram was blocked
15:45 UTC: Mobile internet operators starting to switch off their networks
@DeutscheWelle

https://twitter.com/DougMadory/status/1572657304335716353 (archive)

Internet connectivity for Iran's primary mobile operators were cut in recent hours. #IranProtests2022

Traffic volumes for MCI (AS197207) from @kentikinc:

https://twitter.com/CloudflareRadar/status/1572662811951771648 (archive)

Amid #IranProtests2022), #Internet disruptions have been observed at major #mobile carriers in #Iran🇮🇷.

@CloudFlareRadar data shows significant drops in traffic at AS57218 (Rightel), AS197207 (MCI), and AS44244 (Irancell), as well as at a country level.

https://radar.cloudflare.com/ir?date_filter=last_24_hours

[wkrp]

There are some simple network tests that can help find any ways through the shutdown that may exist. During the January 2022 shutdown in Kazakhstan, it was discovered that TCP ports 3875 and 179 worked, when all other ports were blocked. You can try testing these ports in a mobile web browser. portquiz.net is a server that responds with a web page on all ports.

• http://portquiz.net:3875/
• http://portquiz.net:179/

Or, if DNS resolution is blocked:

• http://35.180.139.74:3875/
• http://35.180.139.74:179/

Here is an Nmap command to run to test all TCP ports. It should run in 11 minutes or less. scanme.nmap.org does not have every port open, but the ports that are not open respond with a RST, so it can still be useful to detect blocking.

nmap -v -v -v -n -Pn -p- --reason -oN 'scanme-allports-%D%T.nmap' --min-rate 100 scanme.nmap.org

nmap -v -v -v -n -Pn -p- --reason -oN 'scanme-allports-%D%T.nmap' --min-rate 100 45.33.32.156

It will be good to know about reachability of DNS resolvers, both of foreign resolvers directly and via domestic ISP resolvers.

dig @185.49.141.38 example.com
dig example.com

On Windows, you can try

nslookup example.com 185.49.141.38
nslookup example.com

I got the address of the resolver 185.49.141.38 from https://dnsprivacy.org/test_servers/; you can try any other resolver. In the output, you are looking for status: NOERROR and an A record response of 93.184.216.34 (at least, that's what I see right now).

[wkrp]

The first major shutdown began about 2022-09-21 16:00 UTC (20:30 IRDT) and ended 6 to 12 hours later, depending on the network.

It was followed by another shutdown that started about 2022-09-22 12:00 UTC (15:30 IRDT) and ended about 8 hours later.

https://twitter.com/CloudflareRadar/status/1573067153036787713 (archive)

After a second set of outages spanning between 6-8 hours, connectivity has once again been restored on Iranian network providers Rightel, Irancell, and MCI.

@Cloudflare data shows that traffic returned at 2025 UTC.

https://radar.cloudflare.com/ir?date_filter=last_24_hours

#KeepItOn
#IranProtests2022

IODA links for exploration:

https://ioda.inetintel.cc.gatech.edu/asn/44244?from=1663221600&until=1663912799
https://ioda.inetintel.cc.gatech.edu/asn/57218?from=1663221600&until=1663912799
https://ioda.inetintel.cc.gatech.edu/asn/197207?from=1663221600&until=1663912799

[wkrp]

At approximately the same time as the start of the shutdowns, there was a large increase of bandwidth at the Snowflake, so much so that it threatens to overwhelm the capacity of the bridge. (This is the bridge that has already had significant engineering and hardware upgrades for scaling.) This is a graph of send/recv bandwidth at the network interface over the past 5 days:

The big crater on 2022-09-22 is where the server was running out of memory and swapping.

We are in the process of making some changes to the server in response to the increased load. We have already doubled the number of tor instances, which relieved some of the CPU pressure. We are also testing some performance optimizations and hope to deploy them tomorrow.

[wkrp]

A third outage occurred starting 2022-09-23 12:15 UTC (15:45 IRDT) and lasted about 8.5 hours.

A fourth outage started at 2022-09-24 14:00 UTC (17:30 IRDT) and is still ongoing.

https://twitter.com/CloudflareRadar/status/1573429947766562830 (archive)

Connectivity was restored to Irancell, Rightel, and MCI in #Iran at 2030 UTC after an 8.5 hour outage, the third one this week.

Analysis of #HTTP & #TLS version usage suggests that selected #UDP blocking may be occurring on some networks as well.

https://radar.cloudflare.com/ir?date_filter=last_24_hours

https://twitter.com/CloudflareRadar/status/1573689073268580354 (archive)

For the fourth consecutive day, #Internet shutdowns have been observed at Rightel, Irancell, and MCI in #Iran🇮🇷.

@Cloudflare data shows today's outages began around 1400 UTC.

https://radar.cloudflare.com/asn/44244?date_filter=last_7_days
https://radar.cloudflare.com/asn/57218?date_filter=last_7_days
https://radar.cloudflare.com/asn/197207?date_filter=last_7_days

#KeepItOn
#IranProtests2022

[mrphs]

A friend just ran the nmap and dig test on AS57218. dig times out. and nmap doesn't get a response back from the host.

All 65535 scanned ports on scanme.nmap.org (45.33.32.156) are in ignored states.
Not shown: 65535 filtered tcp ports (no-response)

PS: I tweeted about this ticket, hoping more technical folks inside the country would see this and run the tests. I will update the thread if I get any more responses.

[wkrp]

My understanding is that people on mobile ISPs are able to access domestic Iranian services even during a shutdown. It would be helpful to know if there are any domestic DNS resolvers that permit recursive queries of foreign domains and are accessible during a shutdown. The idea is to tunnel through an accessible domestic DNS server to reach the outside world during a shutdown.

There are some lists of public DNS servers in Iran:

• https://public-dns.info/nameserver/ir.html
• https://publicdnsserver.com/iran/

You can test whether the resolvers permit recursive queries using a command like the following. Ideally, you run the command on a laptop that is tethered to a mobile phone, during a shutdown.

for res in 213.176.123.5 194.225.62.80 185.161.112.33 2.185.239.136; do dig "@$res" example.com; done

If you don't have a tethered laptop, you can do DNS resolver tests from a mobile phone. You just have to change the system DNS setting (instructions for Android, iPhone) and enter one of the resolver IP addresses above. Then open a browser and try to access any foreign web site, like example.com. It won't work, but you can tell from the error message whether DNS resolution worked.

Error message	Meaning
Server not found	The DNS resolution failed
Connection timed out	The DNS resolution worked
Connection refused	The DNS resolution worked

[wkrp]

A friend just ran the nmap and dig test on AS57218. dig times out. and nmap doesn't get a response back from the host.

Thanks for this.

scanme.nmap.org (45.33.32.156)

The fact that both a hostname and an IP address are listed implies that either forward or reverse DNS resolution must have worked. I'm not sure if the test used the hostname scanme.nmap.org or the IP address 45.33.32.156, but even if you only give an IP address, Nmap will do a reverse lookup to get a hostname if possible.

You can test reverse resolution using the -x option of dig:

$ dig -x 45.33.32.156
...
;; ANSWER SECTION:
156.32.33.45.in-addr.arpa. 3357 IN      PTR     scanme.nmap.org.

It would be interesting if reverse but not forward DNS worked during a shutdown. I don't know of any tunnels that use PTR queries and PTR records, but it's not impossible: dnscat2 can use constrained types like TXT, MX, CNAME, A, and AAAA. But let's try to get more confirmation about whether forward recursive queries work or not.

[mrphs]

New OONI report is out: https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-protests/

A whole lot of things are blocked now. The networks I had access to are all at 0% connectivity based on what CloudFlare Radar is showing 😣

[wkrp]

New OONI report is out: https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-protests/

Besides the shutdowns which started this thread, the report covers:

• New blocking of DoH servers, since 2022-09-20. DoH resolvers that were formerly blocked by TLS filtering (e.g. dns.google, dns.quad9.net) are now additionally blocked by false DNS results for their domain names. Other DoH resolvers are blocked (e.g. doh.dns.apple.com, cloudflare-dns.com) that were not blocked before.
• New blocking of WhatsApp, Instagram, LinkedIn, and Skype.
• New blocking of Apple App Store and Google Play Store in some/more ISPs, since 2022-09-22.
• New blocking of HTTP/3 (QUIC), since 2022-09-22.

The blocking of DoH resolvers is interesting to me. It should be superfluous to block DNS resolution if endpoints are already blocked. Maybe the censors are going for defense in depth. Maybe encrypted DNS was being used for tunneling. Maybe it exposes a weakness: some services are blocked only by DNS and not by, e.g., TLS SNI filtering, therefore it is required to block secure DNS. Or possibly there's no specific intention behind it, just a setting on some firewall hardware.

[gfw-report]

New blocking of Apple App Store and Google Play Store in some/more ISPs, since 2022-09-22.

the blocking of Google Play Store and Apple App Store may limit Iranians’ ability to install or update apps.

The blocking of the application stores creates a typical chicken-or-egg problem in censorship circumvention. That is, users need a bootstrapping to get access to the application stores so that they can download other circumvention tools. Fortunately, the bootstrapping channel doesn't have to be very robust or censorship-resistant; it can be a low bandwidth, high latency channel that only works temporarily. Some bootstrapping channels include:

For Android, getting users an APK file should be enough for bootstrapping. It can be done by sharing the APK files via some low profile channels, for example hosting an APK on an uncensored website and share users a link to it.

---

For iOS, users may have to use the Apple App Store to download the software. One may want to take the advantage of iOS's built-in VPN client that supports IKEv2, IPsec, and L2TP protocols:

• One may use the VPNGate to get publicly available L2TP or IPsec VPN. This may have already been a popular circumvention choice in Iran, given that Iran ranks the second in "countries with most users" as of today September 27, 2022. Specifically,

1. Settings -> VPN -> Add VPN Configuration... , configure as follows:

Description: Gate
Type: L2TP (Try changing it to IPSec if it doesn't work)
server: 219.100.37.100 (Try different IP addresses if it doesn't work)
Account: vpn
Password: vpn
Secret: vpn

2. Save the setting by clicking on the "Done" on the upper-right corner.

3. Select Gate (unkonwn) and click the Status button to turn on the VPN.

• One may also setup IPsec VPN on their own servers with a one-click script. Specifically,

1. On the server, wget https://get.vpnsetup.net -O vpn.sh && sudo sh vpn.sh. Pay attention to the VPN credential information in the script's output.

2. On your phone, Settings -> VPN -> Add VPN Configuration... , configure as follows:

Description: myvpn
Type: IPsec
server: 
Account: vpnuser
Password: 
Secret: 

3. Save the setting by clicking on the "Done" on the upper-right corner.

4. Select myvpn (unkonwn) and click the Status button to turn on the VPN.

[fortuna]

I probed all DNS servers from https://public-dns.info/nameserver/ir.html for the IP of example.com at around 6:39 pm UTC, September 28. I believe that's during the curfew. The results below are resolver_ip, resolver_asn dig_response

$ while IFS=, read -r resolver_ip _ resolver_asn _; do echo -n "$resolver_asn $resolver_ip "; dig +short +time=1 +tries=1 @$resolver_ip unique-$RANDOM.example.com && echo NXDOMAIN; done < <(tail +2 ir.csv | sort -g) | sort -g
6736 194.225.73.141 NXDOMAIN
12880 217.218.127.127 NXDOMAIN
15611 213.176.123.5 ;; connection timed out; no servers could be reached
43754 37.156.145.21 ;; connection timed out; no servers could be reached
43754 37.156.145.229 ;; connection timed out; no servers could be reached
43965 194.225.62.80 ;; connection timed out; no servers could be reached
48715 185.51.200.10 ;; connection timed out; no servers could be reached
48715 185.51.200.50 ;; connection timed out; no servers could be reached
49666 2.189.44.44 NXDOMAIN
50057 185.161.112.33 NXDOMAIN
50057 185.161.112.34 NXDOMAIN
56402 46.224.1.42 NXDOMAIN
56402 46.224.1.43 NXDOMAIN
56547 31.24.234.37 NXDOMAIN
58224 80.191.40.41 ;; connection timed out; no servers could be reached
58303 81.163.3.1 ;; connection timed out; no servers could be reached
60627 185.113.59.253 ;; connection timed out; no servers could be reached
60976 82.99.242.155 ;; connection timed out; no servers could be reached
60976 91.99.101.12 ;; connection timed out; no servers could be reached
202468 185.231.182.126 ;; connection timed out; no servers could be reached
202468 185.97.117.187 ;; connection timed out; no servers could be reached
209596 91.245.229.1 ;; connection timed out; no servers could be reached
212907 185.187.84.15 ;; connection timed out; no servers could be reached

The ASes that returned NXDOMAIN are probably able to access external DNS resolvers.

Edit: In my initial test I was reusing the same domain, which could trigger cached results. It's now using a unique domain per query.

[fortuna]

Looking at Cloudflare radar:

ASes not subject to curfew:

https://radar.cloudflare.com/asn/58224

https://radar.cloudflare.com/asn/12880

https://radar.cloudflare.com/asn/49666

https://radar.cloudflare.com/asn/50057

AS that was added to the curfew

https://radar.cloudflare.com/asn/56402

ASes subject to curfew

https://radar.cloudflare.com/asn/44244

https://radar.cloudflare.com/asn/197207

[abdallahalsalmi]

Irancell (owned in part by MTN Group) and MCCI, a state-owned entity, account for over 60% of Iranian mobile phone users, if not more. The internet shutdowns are clearly aimed at mobile networks to stop the protestors from mobilising and organising (and sharing information too).

[Fardinak]

Hi there 👋

I found this thread a couple of days ago when a friend of mine sent me @fortuna's tweet. Since then I have been running some tests (including the port scan). The nmap results would be irrelevant since we haven't had a shutdown since I've started testing. But in the past couple of days I've been witnessing some strange behaviour.

I first noticed that my VPN client was not detecting my location properly a couple of days ago. My initial thought was that this is an internal issue (caching my IP from the other VPNs I've been testing). Tonight I realized it's much more than that.

Right now, on an AS58224 (TCI) connection I'm getting the following results:

https://isbgpsafeyet.com
Your ISP (AS58224) does not implement BGP safely.

https://radar.cloudflare.com/my-connection
IP address: 162.55.57.188
Geolocation: Germany
AS: 24940 (Hetzner Online, DE)

https://browserleaks.com (connection timeout)

https://www.dnsleaktest.com
5.200.200.26
5.200.200.50

$ dig +short whoami.akamai.net
;; communications error to 5.200.200.200#53: timed out
5.200.200.50

Note that the Geolocation and AS detected by Cloudflare is not consistent with the other results.

Switching over to AS197207 (MCCI) using an iPhone's hotspot returns the following results:

https://isbgpsafeyet.com
Your ISP (Mobile Communication Company of Iran, AS197207) does not implement BGP safely.

https://radar.cloudflare.com/my-connection
IP address: 65.108.155.56
Geolocation: Helsinki, Finland
AS: 24940 (Hetzner Online, DE)

https://browserleaks.com/ip
County: Iran
Region: Tehran
Network: AS197207
DNS Leak Test: Found 42 Servers, 6 ISP, 4 Locations

https://www.dnsleaktest.com: Extended test
21 results, 5 ISPs, 5 locations

$ dig +short whoami.akamai.net
195.27.183.45

On the iPhone using the Net Analyzer app shows two 10/8 IPs as DNS servers when using MCCI cellular and 5.200.200.200 when using TCI over Wi-Fi.

The DNS Leak tests return a variable number of servers (between 20 to 60) a few of which (2 or 3) are usually the correct one. But based on these, I'm either getting service from Layer 3, Cloudflare, Google, Vodafone or Lumen and am located anywhere from the UK to Japan!

Anyways, thought this might be of interest. I'm also curious to know what you think about this situation.
I'll keep an eye out and run the port scan if there is another shutdown.

p.s. all tests were run on a fresh linux VM with a dedicated USB Wireless card and no manual network configuration.