OpenVPN cannoli, an Iranian fine pastry recipe

An OpenVPN adaptation of one of the most iconic of Sicilian desserts, the cannoli, here in the Iranian recipe. It will satisfy even the most delicate palates and connect all the taste bud in your tongue!

Please note that this article is dated August 2023. This recipe might have to be adapted in the future, as the ingredients could change or become unavailable in your area.

Why cannoli

And why other recipes did not (always) work

Countries which have a strong censorship system will of course do everything to block and filter the internet connectivity.
While working with the objective of fighting the Great Firewall of Iran (GFI), I discovered that:

  • changing ISP does not necessarilty circumvent the restrictions, it is not true that one provider will have less restrictive rules than an other
  • changing road-warriors location does change the restriction level
    • on some cities the same provider applies fewer restrictions (this has been proofed and tested)
    • the capital, Theran (and the surroundings) are, to my experience, the worst places where to originate a connection (either from mobile and landline).
  • obfuscated and hidden VPN protocols (i.e. using DNS, ICMP and protocols generically not filtered), like the mighty SoftEther https://www.softether.org/ VPN project, could in theory allows connection even when protocol fingerprinting is applied at TCL provider level but:
    • being able to connect is not the same as being able to work
    • ISP limit the bandwidth over unknown/foreign countries IP addresses, up to the level that the connection is useless for any decent work
  • routing VPN protocols via HTTPS proxies (i.e. HAProxy) to avoid detection, works in general, but then bandwidth limitation applies (not counting the extra latency/overhead added by the proxy)
  • SNI are inspected and filtered

Bottomline, GFI uses a mixture of bandwidth limitation and fingerprinting which makes most of the efforts useless.

This cannoli recipe was one of the many attempts - and the only successful, as it exploit the need of a restrictive country (in this case Iran) to still be connected to neighbors countries: i.e. cannoli use legit traffic to circumvent restrictions.

Even if your entry-point does not seem to be filtered, always consider that it is better to be safe than sorry. Direct encrypted connection to your private VPN might not be seen positively by the Iranian government.

Given the low complexity and cost of this setup, any further investigation of a state actor toward your VPN road-users will be easier to mitigate with the cannoli setup - or you could face the uncomfortable situation of explaining why you are exporting data outside Iran to a foreign EU/US country.

What do I need to make this recipe?

  • An account on a cloud vendor which has datacenters in a friendly Iranian country, like Quatar, Turkey, etc. (e.g. both Azure and AWS have middle east availability zones)
  • One or more SSH accessible servers, Linux is preferred, as they might be easier to spin-up and are cheaper
  • One OpenVPN server configured to use TCP as the transport protocol
    • You can use any port you want
    • You can configure OpenVPN as you want
    • You can locate the OVPN server anywhere in the world, but this recipe assumes you are going to use your company road warriors VPN connection.
  • One road-warrior VPN user sitting in an Iranian location, i.e. Theran with a working internet connection
    • Different local providers might provide different outcomes in terms of speed and reliability of the tunnel
    • The OpenVPN cannoli seems to work well with many TLC, as it assumes the use of neighbours low-filtered IPs

Adjust quantities according to the amount of guests

The table set (TL;DR)

The diagram shows the table set. Our guests (the road warrior users) will originate the connection to the remote OpenVPN server from the tunnel, using the localhost:8443 address:port.
The cannoli SSH tunnel will route the traffic to the company firewall, and from there the OpenVPN server will do the magic, allowing seamless access to the corporate local area network.

More cannoli the merrier, you do not want you guests to starve!
It is not guaranteed that the IP provided will not be blacklisted - add more tunnels to lower the probability.

Bake the cannoli shell

The shell is the most important part of the recipe.
Choose poor ingredients and you will have a poor user experience. To identify the perfect taste, it’s a trial and error process.
My experience is that Azure Middle East datacenters (located in Quatar) are quite accessible (and reliable in throughput), even from the country’s capital (which seems to have the most severe traffic filtering rules in place).

The shell could be just a vanilla linux with one or more users.
The only mandatory service is an openssh server. You’ll have it already in place the moment the server spin-up is completed.

Again, more shells the merrier

Should you ruin your cannoli, a fallback shell is always welcome. After all these are just micro-instances, extremely cheap but important for holding the OpenVPN ricotta!

Check the cooking time

You’ll want a perfectly baked shell, always check the cooking time! Verify that your guests, sitting in Iran, will be able to:

  • reach the shell: they can connect to the SSH port and authenticate
  • have a decent upload/download speed
    • ask a guest to upload some file, i.e. scp ./ubuntu.img user@openvpn-relay-server01: (where user is a valid username in the Quatar based linux server and the openvpn-relay-server01 is the IP address or domain name of the newly created linux server)

To avoid credential sharing, use a certificate based authentication mechanism. Ask to your guest their id_rsa.pub file and add it to the ~/.ssh/authorized_keys file.

The ricotta filling

If you are lactose intolerant, worry no more! The OpenVPN cannoli uses just a thin layer of SSH port forwarding.
From the Arch Wiki https://wiki.archlinux.org/title/OpenSSH :

Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the -L switch and it is accompanying forwarding specification in the form of <tunnel port>:<destination address>:<destination port>

The command:

ssh -L 8443:vpn.mycompany.com:8443 user@openvpn-relay-server01

Will use SSH to login to and open a shell on openvpn-relay-server01, and will also create a tunnel from the local machine’s TCP port 8443 to vpn.mycompany.com on port 8443. Once established, connections to localhost:8443 will connect to the company OpenVPN server port.

How to serve

Once the filling is ready, just configure your OpenVPN client to connect to the local port 8443, for example:

proto tcp
remote 127.0.0.1 8443

This will establish an OpenVPN connection

See Also