PGP Public Key

Version: GnuPG v2


An alternative approach to so-called WebRTC leaks

Posted on Reddit here:

Recently there were a lot of discussions about the WebRTC IP Leak. Almost all of them are talking about a “Security flaw” or treat it as a bug.

However, many articles about the WebRTC [leaks] talk about a solution: disable WebRTC in favorite browser.
Two questions:

  • Is it really a “Security flaw” that needs to be fixed in browsers? Look at browsers bug-reports to understand how many different opinions exist on this.
  • Why the browser can go outside the VPN tunnel? How many app/protocols can do the same things of the WebRTC leak? So, is disabling WebRTC a sufficient solution for those who use a VPN to avoid exposing their ISP IP address or traffic?

I will explain details of the issue. But first, if you are connected to a VPN service right now, try this: (source available here )

or, under Unix try this (try also as root):

for s in `ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d'`; do curl --interface $s; done

Is your real ISP IP leaked?


When a user connects to OpenVPN, the main interface (ethernet, wifi etc) is still available (also to talk with the VPN server itself).
And another network interface is opened (tun/tap).
This is the scope of OpenVPN: create a tunnel.

As a plus, OpenVPN can be configured to push a directive from the server to their client: “redirect-gateway”.
This tells at client-side that ALL traffic needs to be redirected inside the tunnel by default.

Almost all VPN services use a specific option of that directive: “redirect-gateway def1”.
From OpenVPN manual

def1 — Use this flag to override the default gateway by using and rather than This has the benefit of overriding but not wiping out the original default gateway.

Now, this means that the original route are still active, but there are other routes created by OpenVPN that override the original based on precedence.
But is a route assigned to the standard interface, while the new and are assigned to the TUN interface.

In every OS, when a connection/socket is opened, the program can choose a specific network interface that needs to be used.
This is not common, because most applications don’t need that and let the OS use the default network interface.

The program above do exactly this: bind to specific network interface to query an external what is my ip address service.
When binding to the standard interface, the overriding rules of OpenVPN are simply ignored, at least under Windows.

I think browsers do the same thing in WebRTC discovery.

Can a VPN service based on OpenVPN resolve the issue server-side, transparently to their users?

Simply don’t use the def1 option in redirect-gateway directive.
Without def1, OpenVPN client removes totally the route, and re-creates it at disconnection.

But I don’t recommend this approach: with def1, if the OpenVPN process is terminated, the overriding routes are automatically deleted or unused, and traffic continues to flow over the standard interface.
Without def1, if OpenVPN process is killed/terminated, the user remains without any route for his/her traffic.

For me, a good VPN service needs to use the def1 option, for the final consideration below.

Final consideration

WebRTC IP Leak is not a fault of browsers.

It is not a fault of OpenVPN (that is designed to be a Tunneling software, not an Always hide my traffic software).

It is a fault of users, because they trust the standard OpenVPN client for things out of its scope, or trust a badly-written VPN service client software.

Users need to use a VPN service that has a software addressing this kind of issue, or need to understand how to configure a firewall or a router.

*Disclaimer: *
I’m the author of the client software of a known VPN service. Anyway I don’t cite it in this reddit.


Update: sources released on GitHub.

I’m done some game/experiment during my study on DK2 gameplay, this is one of them (about body movement and reflexes). Maded with Unity 5.0.18 Indie and Oculus 0.4.4 sdk.


YouTube Preview:

A guy that enjoy my game (with the correct gameplay: without controller!)

Windows: (45 mb)
OS X (UNTESTED): (47 mb)
Linux (UNTESTED): (57 mb)

The game need an initial calibration, to detect the maximum and minimum position a player can move it’s head.
Press X to reset the calibration. Press R to reset Oculus Rift orientation.
Press SPACE to start (and restart at game-over).

Can be played seated, but i recommend to play it stand up, with hands on desk.

Works at 75fps with my GTX 570 on an old i7. Press F11 to see the FPS, and 0,1,2,3,4,5 to change graphics quality (0 fast, 5 is best).

At game-over, press SPACE to reset and look left to check if you beat your highscore.

I released all source-code under public domain. Not well commented, it’s just an experiment. It works with Unity Indie. (85 mb)

The zip contain parts of some third-party assets, but all of them are totally free in Unity Asset Store.

Music by Imphenzia: – i used the watermarked version to allow me to release the entire project out-of-the-box under open-source.

No more improvement are planned, unless people like it 😛

My best score is 4307 meters 😛 Enjoy!

Sphere spirals, 1958, MC Escher

Immagine inviata

Immagine inviata Immagine inviata Immagine inviata Immagine inviata Immagine inviata

Download MP4

Rendering di una isosuperficie ispirata da un’opera di Escher, Sphere Spirals.
Formule per Povray da “Almost Sphere Spirals” by Tor Olav Kristensen (2002)

‘Tor Olav Kristensen’ said

An isosurface shape inspired by M.C. Escher’s “Sphere Spirals” (“Bolspiralen”) woodcut print from 1958. The edges of the four spiraling bands on the sphere can be formed by an inverse stereographic projection of eight infinite logarithmic spirals in a complex plane tangent to a Riemann Sphere onto it’s surface. I found some useful information about this shape here.

Shot 1: Twisting rate a 1.5, 4 bande. 1920 x 1080. Rendering: 2 ore circa.
Shot 2: Twisting rate a 0.1, 1 banda. 1920 x 1080. Rendering: 20 ore circa.
Shot 3: Twisting rate a 0.5, 4 bande. 1920 x 1080. Rendering: 8 ore circa.
Shot 4: Twisting rate a 1.9, 12 bande. 1920 x 1080. Rendering: 1 ora circa.
Shot 5: Twisting rate a 1.0, 4 bande, fog. 1920 x 1080. Rendering: 8 ore circa.
Animazione: Twisting rate variabile da 1 a 3, 4 bande. 640 x 360, 30 fps, 600 fotogrammi (20 sec). Rendering: 2-3 settimane su 3 macchine circa, tempo variabile da 3 ore a mezz’ora per ogni fotogramma.

Tutti con antialiasing di default, senza radiosità.
In dettaglio, i riflessi non incidono particolarmente nei tempi di rendering. E’ l’isosuperficie che “ammazza”, in particolare con bassi valori di twisting rate.

Sorgenti (PovRay 3.6 richiesto, 3.7 consigliato): ini, pov.