Jump to content
Not connected, Your IP: 18.233.223.189
KenAV

Anonymity Check site says "MTU 1397 = VPN Fingerprint

Recommended Posts

Posted ... (edited)

I tried the web site "Anonymity Check".  It does 15 checks.  The only "thumbs down" was

VPN Fingerprint    MTU 1397  

Any thoughts on:

* Why an MTU of 1397 is a "VPN Fingerprint"
* Why Eddie decided to use an MTU of 1397 ?

Thanks.

The setup is Windows Vista 32-bit, Eddie 2.16.3, Firefox 52.9.0 ESR for viewing the web site, which is at:

https://2ip.io/privacy/

Edited ... by KenAV

Share this post


Link to post

This is just a way to make the tunnel efficient without packet fragmentation for most users.
You can adjust the --tun-mtu and mssfix flags to be any value you want.

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/


Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post


Link to post

To be of more help to you, there is a fixed value for how big a packet is allowed to be before two or more packets get sent to comprise the original packet. The widespread default on the internet especially is 1500 bytes. Now, before you get to send your data, packets need some metadata for all the networking equipment on its way to make it processable - they're the headers. You need to squeeze all that info and your traffic data into every single packet.

(Un)Fortunately, headers have a fixed size. The IPv4 header plus the UDP header for example is 20 + 8 bytes long, leaving you with 1500 - 28 = 1472 bytes of space in a packet.
Now, OpenVPN builds a tunnel on top of this, further decreasing the space. And then you're browsing a website inside this tunnel via TCP over IPv4 or so, it grows even smaller. And so on, and so on. Your setup ended up with 1397 bytes which is not normal. If it were, you would have 1460 (TCP over IPv4 connection is 20+20, so: 1500 - 20 - 20 = 1460). And setting the MTU to account for this wouldn't do you any good because somewhere on the way packets might get fragmented.


NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post

Ho, there !

I tried the same website, but I got *two* thumbs-downs : the same MTU issue as KenAV, but also «Defining tunnel (two way ping) found». Can someone explain what that is and means ?

   

Share this post


Link to post

Essentially, passive TCP/IP fingerprinting by analyzing some timings. The developer of WITCH? once wrote an article on Medium about it.


NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post

I believe the 2 way ping thing is something like this.  Your web browser pings the test site and the test site pings the IP you appear to be at (VPN server).

Your browser ping goes from your PC to the VPN server to the test site.  The test site ping is just to the VPN server.  So, there's a good chance the latency of the ping from the browser will be higher.  I'm sure there's some fudge factor that they consider "normal" difference because routes are not always symmetric anyway.  But, a difference beyond the fudge factor is a good indication that a "proxy" is being used.

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...