Russia has started tentative blocks of the OpenVPN protocol on several mobile internet service providers since last week.
The fact became known after several Moscow-based users complained about their ability to connect to OpenVPN-powered services through the MTS, Tele2, Megafon, Colna, Yota, and Beeline providers.
While connectivity has been restored in some cases, problems persist on several providers, with many users reporting that even when they achieve to establish a connection, they lose it after about 10 seconds.
The situation prevents internet users in Russia from accessing the web privately. At the same time, organizations in Moscow that use OpenVPN as part of their corporate network design currently suffer from catastrophic outages.
The latter is an excellent example of why attempting to block entire internet communication protocols, let alone widely used ones, is never a good idea, no matter how imperative the need for censorship may be.
Russia vs. VPNs
The Russian state has already blocked or prohibited the use of the most reliable and trustworthy VPNs, allowing only those that agreed to connect their services to the FGIS database (permitted content) to continue operating in the country. Notable services blocked in Russia are NordVPN, ExpressVPN, ProtonVPN, VyprVPN, Opera VPN, and PrivateTunnel.
More recently, Moscow-based security company Kaspersky also decided to retract its VPN product, Secure Connection, away from the Russian market, opting not to explain why it has reached this decision.
However, many of the banned providers reverted to using routing servers located just outside the Russian border, continuing to support their Russian user base, albeit at reduced speeds and server options, which is the inevitable result of implementing unfavorable bypassing solutions.
Blocking all traffic that appears as OpenVPN traffic makes logical sense as a next step in the Russian state’s effort to curb the use of restricted VPN products, so these tentative small-scale blocks might be just a first-phase test-bed. In fact, there have been several reports of Russian ISPs testing blocks on IKEv2 and WireGuard in other regions, so it is clear that the country’s authorities experiment with this type of aggressive censorship.
What Can Russians Do?
The environment for Russian netizens who value their privacy and would like to continue accessing “unapproved” internet spaces or information sources is getting increasingly hostile, and the methods to bypass all the blocks imposed at multiple levels are, unfortunately, more challenging to implement.
A solid way to bypass protocol-based blocks would be to select a VPN product offering multiple protocol options and try connecting with one Russia’s internet watchdog does not actively target.
A second block-circumvention method would be to use special obfuscating tools that make OpenVPN traffic appear as regular internet traffic, making it less likely to raise flags on the ISP’s checking points. One effective tool that does this is ‘GoodbyeDPI,’ which even releases a special version for Russia-based users.
ExpressVPN and NordVPN should be able to bypass this problem thanks to the ‘Domain Fronting‘ system they incorporate into their products. Tunnelbear also has a ‘GhostBear‘ system that obfuscates network traffic by randomly adding data or trimming data packets, making deep inspection impossible, thus avoiding automated blocks.
Finally, there’s the option of using the Shadowsocks encryption protocol, which offers a fast tunnel proxy helping bypass aggressive internet censorship measures. Shadowsocks has been successfully used against the “Great Firewall” of China, masking VPN traffic and encrypting all data packets so they cannot be scrutinized by intermediaries or providers.
Amazon Facing $30 Million Fine for Ring Privacy Violations
How to configure STUNNEL+OPENVPN (install stunnel along with openvpn)?
Create using a Centos 7 OS:
1. Install OpenVPN Server:
wget https://raw.githubusercontent.com/Angristan/openvpn-install/master/openvpn-install.sh -O centos7-vpn.sh
wget centos7-vpn.sh
chmod +x centos7-vpn.sh
./centos7-vpn.sh
nano /etc/openvpn/server.conf
port 11235
proto tcp
if firewall-cmd –state == running
firewall-cmd –list-all
firewall-cmd –add-masquerade –permanent
firewall-cmd –query-masquerade
firewall-cmd –permanent –direct –passthrough ipv4 -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
firewall-cmd –reload
else (when ipTables is used)
iptables -L –line-numbers -n
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
yum install iptables-services
service iptables save
2.Add OpenVPN Client:
mobile_android: https://play.google.com/store/apps/details?id=net.openvpn.openvpn
desktop: https://openvpn.net/community-downloads/
Tick in the app ‘seamless tunnel’
client.ovpn:
proto tcp-client
remote 127.0.0.1 11211
route 255.255.255.255 net_gateway
3. Compile STunnel Server:
cd /tmp
wget ftp://ftp.stunnel.org/stunnel/archive/5.x/stunnel-5.70.tar.gz
groupadd -g 51 stunnel && useradd -c “stunnel Daemon” -d /var/lib/stunnel -g stunnel -s /bin/false -u 51 stunnel
tar xzvf stunnel-5.70.tar.gz
cd stunnel-5.70
./configure –prefix=/usr –sysconfdir=/etc –localstatedir=/var
make
make docdir=/usr/share/doc/stunnel-5.70 install
install -v -m750 -o stunnel -g stunnel -d /var/lib/stunnel/run
chown stunnel:stunnel /var/lib/stunnel
nano /etc/stunnel/stunnel.conf
pid = /var/run/stunnel.pid
cert = /etc/stunnel/certs/servert_cert.pem
output = /var/log/stunnel
client = no
[server_openvpn]
accept = 4443
connect = 127.0.0.1:11235
;; “TIMEOUTclose = 0” is a workaround for a design flaw in Microsoft SSL
;; Microsoft implementations do not use SSL close-notify alert and thus
;; they are vulnerable to truncation attacks
TIMEOUTclose = 0
firewall-cmd –permanent –add-port=4443/tcp
firewall-cmd –reload
iptables -I INPUT -p tcp –dport 4443 -m state –state NEW -j ACCEPT
service iptables save
Make certificate:
openssl req -new -x509 -days 3650 -nodes -out servert_cert.pem -keyout servert_cert.pem
openssl x509 -subject -dates -fingerprint -in servert_cert.pem
chmod 600 /etc/stunnel/servert_cert.pem
stunnel /etc/stunnel/stunnel.conf
openssl dhparam 2048 >> /etc/stunnel/servert_cert.pem
nano /etc/systemd/system/stunnel.service
[Unit]
Description=TLS tunnel for network daemons
After=syslog.target network-online.target
[Service]
LimitNOFILE=20480
ExecStart=/usr/bin/stunnel /etc/stunnel/stunnel.conf
ExecReload=/bin/kill -HUP $MAINPID
Type=forking
WorkingDirectory=/etc/stunnel
TimeoutSec=600
Restart=always
PrivateTmp=false
[Install]
WantedBy=multi-user.target
Alias=stunnel.target
systemctl enable stunnel
systemctl start stunnel
4. Stunnel-client
mobile_android: https://github.com/comp500/SSLSocks
https://play.google.com/store/apps/details?id=link.infra.sslsocks
desktop: https://www.stunnel.org/downloads/stunnel-5.70-win64-installer.exe
stunnel.cnf
client = yes
[openvpn_client]
accept = 127.0.0.1:11211
connect = :4443
CAfile = servert_cert.pem
verifyPeer = yes
systemctl restart openvpn-server@server.service
systemctl status openvpn-server@server.service -l
systemctl restart stunnel
systemctl status stunnel.service -l
*servert_cert.pem must be copied from the server to a local gizmo.
but there is a missing part from the text which i have added earlier:
client.ovpn:
proto tcp-client
remote 127.0.0.1 11211
route 255.255.255.255 net_gateway
correct is
route 255.255.255.255 net_gateway
like
route 45.79.181.19 255.255.255.255 net_gateway
Moreover, a server-side bundle of elements “openvpn – stunnel’ sometimes doesn’t allow to launch OpenVPN service when set to the same local port {when firewalld service is on, i guess}, like
cat /etc/openvpn/server.conf
port 33433
&
cat /etc/stunnel/stunnel.conf
[openvpn_server]
connect = 127.0.0.1:33433
hence, the ports should differ…
It seems they had another go for blocking VPNs (both OpenVPN and WireGuard) today?
https://twitter.com/jonnytickle/status/1688870016190443520
I find this blog to be misleading or inaccurate at best based on my personal experiences.
It’s mentioned “notable services blocked in Russia are NordVPN, ExpressVPN, ProtonVPN, VyprVPN, Opera VPN, and PrivateTunnel”.
The writer goes onto to contradict himsellf where he writes “ExpressVPN and NordVPN should be able to bypass this problem thanks to the ‘Domain Fronting‘ system they incorporate into their products.”
I was unable to prevent my internet access from being blocked when using a VPN. Despite using various settings and protocols, including OpenVPN and obfuscated servers, I was still blocked when using a VPN. Nord VPN and Express VPN support were unable to help me bypass the block from several websites including financial institutions.
My research showed that the VPN address I was using was easily identifiable as a VPN and some sites are blocking entire ranges of IP addresses. This makes it almost impossible to prevent your internet access from being blocked when using a popular/common VPN like Express VPN and Nord VPN.
Additionally, in light of current sanctions against Russia by the EU and USA, I find it disturbing that countries like Germany continue to provide them with sanctioned goods and services. Moreover, I can’t feel “bad” for a country and its people if they support Putin’s regime.
Many social media and texting apps in North America like Nextplus block VPN. Wechat knows your actual location even if you spoof your location and use a VPN. So why the testing?
Putin, what is this behavior?
Great post! Heinrich. I feel sorry for those living in Russia.
You feel sorry for Putin supporters in Russia ? Anyway, it appears someone is infatuated with Heinrich.
The mysterious user I see…