Network shutdown, all around Kazakhstan

Here we go again.
Government blocked several social networks, totally shutdowned mobile network, caused by riots and meetings all around Kazakhstan. [1]
Messenger such as Telegram and WhatsApp is blocked. Mobile networks from Altel, Beeline, Tele2, Activ operators are not working, tried on all network types(LTE,3G,2G). Have reports from different regions, cities, and even from village. At least, mobile network shutdowned at 01:06(UTC+6) file:///tmp/1.jpg 10.293s error: Get "": net/http: TLS handshake timeout

Люди говорили, что ничего не работает, а Instagram работает. Можете проверить?

Cloudflare Radar shows that the full shutdown happened after 10:30 UTC (16:30 local time) [2022-01-05]. But it was preceded by restrictions to mobile Internet access yesterday [2022-01-04].

The first disruptions reported affected mobile services, and we can see that at around 14:30 UTC yesterday, January 4, 2022, there was significantly less mobile devices traffic than the day before around the same time.

When we focus on other ASNs besides Kaz Telecom such as the leading mobile Internet services Tele2 or Kcell we can see a big drop in traffic yesterday [2022-01-04] after 16:00 UTC, confirming local reports. Mobile traffic did not drop to zero which may indicate throttling rather than a full shutdown. Today [2022-01-05], however, the Internet, mobile or not, is shut down.

Yesterday, January 5, 2022, after 18:00 UTC and for around three hours there was a return of some Internet services that happened at the same time Kazakh President Kassym-Jomart Tokayev announced in a televised speech that he appealed to a Russia-led security bloc to assist and “protect the state”. After 21:30 UTC the Internet shut down resumed. (archive)

@mushroom, do you know if normal DNS traffic (UDP port 53) is also shut down? I am thinking of the 2019 shutdown in Iran, where it was discovered that DNS was not blocked and that DNS tunnels might have worked to restore access.

If DNS is not blocked, then we can prioritize setting up some dnstt proxies.

@tango one guy wrote me from Kazakhstan right now. He said that DNS works and its possible to use it. But need to setup proxy servers

Okay. If you know someone who knows how to use a Unix command line, here is a test to see if dnstt will work. I have set up a dnstt-server that prints the current time when you connect to it. You may have to compile dnstt-client and give the user a binary, if they are not able to download the source code. In one terminal, run dnstt-client:

dnstt-client -udp -pubkey 6f78064ecc2147e8f5de5c565e4ad1e6aa28f866b2d28c3685ceca2697a37470

In another terminal, connect to the client side of the tunnel:

nc -v 7000

The dnstt-client terminal should show that a stream began and ended:

2022/01/08 17:25:28 begin stream XXXXXXXX:3
2022/01/08 17:25:29 end stream XXXXXXXX:3

The other terminal should show the current time from the server:

Sat 08 Jan 2022 05:25:28 PM UTC

If it does not work, try again, this time sending queries recursively through the ISP resolver (i.e., nameserver from /etc/resolv.conf) instead of connecting to the dnstt-server directly.

dnstt-client -udp <ISP_DNS_RESOLVER_IP>:53 -pubkey 6f78064ecc2147e8f5de5c565e4ad1e6aa28f866b2d28c3685ceca2697a37470

You have to use -udp mode. -doh and -dot mode are not likely to work during a shutdown. Unfortunately, -udp mode is easy to detect and block, if the censor knows what to look for. But the contents of the tunnel will still be encrypted.

If the manual test works, the easiest immediate solution to get access is probably to use one of the third-party Android VPN apps that has dnstt capability. I am not involved with any of these, and I don’t know whether they are actually trustworthy or safe. This is not an endorsement. I think they make you watch and advertisement before you get access. But they will be good enough for a test, and perhaps to bootstrap a more stable connection.

Here are a few apps I know of. You can find these in the Play Store with a search for “dnstt” or in some cases “slowdns”. With all of these, you have to download a primary app, plus a secondary dnstt plugin app. If the user cannot access the Play Store, it should be possible to download the APK files and send them through another channel.

You can find some video tutorials for these on YouTube, for example:

If these tests work, a next step is probably to talk to Access Now about establishing proxy servers. You can set up dnstt as a SOCKS proxy, a Tor bridge, a Shadowsocks plugin, and in other ways.

From IODA, it looks like access has been partially restored a few times, for a few hours each:

You can see the same pattern in AS9198 (KAZTELECOM-AS). But, for example, AS8200 (UPLINK-AS) only shows the 2022-01-08 interval of connectivity, not the 3 earlier ones.

That guy already tunnel traffic via dnstt to his own server. It works. Speed isn’t high, but possible to write text massages.

It should be possible to run ICMP tunnel or something. I’m pretty sure if DNS is working, than not all protocols with direct connectivity are blocked.

ICMP не работает. Я пробовал снаружи пингануть пару адресов, но ни один не ответил. Изнутри ICMP идёт только к TCP, UDP не работает, за исключением dns на 53 к операторскому и гугловскому резолверам. Вообще, у каждого провайдера свой тип блокировки. Сейчас пишу про Билайн, но говорят, что на Казахтелекоме намного проще, там можно просто https проксей. Но, ещё раз говорю, в каждом регионе и у каждого оператора свои заморочки.

SOCKS5 proxy 3785 port works fine. Not sure why, VoIP using skype and other services works as well, so I guess 3785 may be used for VoIP

in general, it’s easy to configure in telegram, but if clients are able to configure proxy on their OS(for example using proxifyer) https and all other traffic works as well.

This has been tested in at least 3 regions.

That’s great, thank you for the information.

I am not familiar with that one either. nmap-services calls it bfd-echo “BFD Echo Protocol”. RFC 5881 says it is a UDP protocol:

BFD Echo packets MUST be transmitted in UDP packets with destination UDP port 3785 in an IPv4 or IPv6 packet.

comment is saying that proxy only works on main provider in Kazakhstan - KazakhTelecom.

Yeah, if it’s not VoIP I have no idea why it works. I guess people found it out by brute-forcing different ports

Also, working VoIP makes me think that there are other ports open on this provider as it also provides landline in Kazakhstan

Here is an obfs4 bridge on port 3785 (IPv4 and IPv6) to try in Tor Browser:

Bridge obfs4 DD9769A0D6A9F18C24FCE731583597012E66273F cert=AEu2dF5cSjzQwA8kDx4R+38u10TReImk3ERjWFmzBGA0tPGyFxnsJRke5iSBef6+QDejew iat-mode=0
Bridge obfs4 [2400:8904::f03c:92ff:fe93:f42d]:3785 DD9769A0D6A9F18C24FCE731583597012E66273F cert=AEu2dF5cSjzQwA8kDx4R+38u10TReImk3ERjWFmzBGA0tPGyFxnsJRke5iSBef6+QDejew iat-mode=0

Documentation for entering bridges:

If this works, we may be able to set up more, for as long as it lasts.

Hello, I am that guy from Kazakhstan. Everything is as zhenyolka says. (Beeline)

The IPv4 obfs4 bridge is working!

I did some port scans. It looks like some other ports to try are 179, 646, 3784, 3785, 4784, 5060.

First I did a scan to see if any hosts in the /24 neighborhood of were reachable on port 3785. Only one of them was, (whois), which is part of “National Information Technologies Joint-Stock Company”:

# nmap -PS3785 -sn -n
Nmap scan report for
Host is up (0.21s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 15.57 seconds

Then, I scanned all the ports on that host. 6 ports were responsive, including 3785:

# nmap -n -PS3785 -p- --reason
Nmap scan report for
Host is up, received reset ttl 236 (0.21s latency).
Not shown: 65529 filtered ports
Reason: 65529 no-responses
179/tcp  closed bgp           reset ttl 233
646/tcp  closed ldp           reset ttl 236
3784/tcp closed bfd-control   reset ttl 234
3785/tcp closed bfd-echo      reset ttl 234
4784/tcp closed bfd-multi-ctl reset ttl 233
5060/tcp open   sip           syn-ack ttl 50

Nmap done: 1 IP address (1 host up) scanned in 344.21 seconds

A port scan could also be a way to discover what foreign ports are accessible from inside Kazakhstan. You need to target a host that responds to every port (with either a SYN/ACK or a RST), like Any port that has reason syn-ack or rst is making it through the shutdown. Any port that has no-response is blocked by the shutdown.

# nmap -v -n -Pn -p- -T4 --reason
Nmap scan report for (
Host is up, received user-set (0.23s latency).
Not shown: 65531 closed ports
Reason: 65531 resets
22/tcp    open  ssh        syn-ack ttl 55
80/tcp    open  http       syn-ack ttl 55
9929/tcp  open  nping-echo syn-ack ttl 56
31337/tcp open  Elite      syn-ack ttl 56

Nmap done: 1 IP address (1 host up) scanned in 108.98 seconds
# nmap -v -n -Pn -p- -T4 --reason -6
Nmap scan report for (2600:3c01::f03c:91ff:fe18:bb2f)
Host is up, received user-set (0.23s latency).
Not shown: 65532 closed ports
Reason: 65532 resets
22/tcp    open  ssh     syn-ack ttl 55
80/tcp    open  http    syn-ack ttl 56
31337/tcp open  Elite   syn-ack ttl 56

Nmap done: 1 IP address (1 host up) scanned in 146.68 seconds

I see you have already set up the bridge. But Softether VPN also allows to encapsulate VPN in DNS or ICMP. I don’t know if this is available for public VPNGate servers.