How do websites know if you're coming through a VPN?

On Wed, 1 Jul 2020 13:31:09 +0100, Andy Burns wrote:

Yousuf Khan wrote:

The VPN packets would have all kinds of variable lengths depending on
the level of compression and encryption. The carrier TCP/IP wouldn't
even know what kind of data is flowing over it, nor care.

The carriers don't care, but it sounds like netflix etc do care, and if
they never see 1500 byte frames from you, even in a bulk transfer,
you're using a VPN

Are you sure about that? I would expect the VPN provider to initiate a new
connection upon exit and not just de-encapsulate the incoming stream. I'm
not saying you're wrong, just that I'm surprised.

In article , Char Jackson
wrote:

The VPN packets would have all kinds of variable lengths depending on
the level of compression and encryption. The carrier TCP/IP wouldn't
even know what kind of data is flowing over it, nor care.

The carriers don't care, but it sounds like netflix etc do care, and if
they never see 1500 byte frames from you, even in a bulk transfer,
you're using a VPN

Are you sure about that? I would expect the VPN provider to initiate a new
connection upon exit and not just de-encapsulate the incoming stream. I'm
not saying you're wrong, just that I'm surprised.

he's wrong.

an mtu less than 1500 does *not* mean vpn.

cellular networks, for example, usually have smaller mtus.

On Wed, 01 Jul 2020 11:47:51 -0400, nospam wrote:

In article , Char Jackson
wrote:

The VPN packets would have all kinds of variable lengths depending on
the level of compression and encryption. The carrier TCP/IP wouldn't
even know what kind of data is flowing over it, nor care.

The carriers don't care, but it sounds like netflix etc do care, and if
they never see 1500 byte frames from you, even in a bulk transfer,
you're using a VPN

Are you sure about that? I would expect the VPN provider to initiate a new
connection upon exit and not just de-encapsulate the incoming stream. I'm
not saying you're wrong, just that I'm surprised.

he's wrong.

an mtu less than 1500 does *not* mean vpn.

cellular networks, for example, usually have smaller mtus.

OK, thanks.

nospam wrote:

he's wrong.

you're in black/white argumentative mood, I see

an mtu less than 1500 does *not* mean vpn.

I didn't say that small MTU alone is enough to be sure a VPN is in use,
nor that only VPNs cause small MTU, but it might be one indication taken
with others ...

In article , Andy Burns
wrote:


an mtu less than 1500 does *not* mean vpn.

I didn't say that small MTU alone is enough to be sure a VPN is in use,

In article , Andy Burns
wrote:
The carriers don't care, but it sounds like netflix etc do care, and if
they never see 1500 byte frames from you, even in a bulk transfer,
you're using a VPN

the phrase "you're using a vpn" leaves no room for doubt.

nor that only VPNs cause small MTU, but it might be one indication taken
with others ...

not a reliable one, since there are many reasons for a smaller mtu.

detecting a vpn is a lot easier and more reliable by looking up who
owns the ip block.

On Wed, 1 Jul 2020 07:56:03 -0400, Yousuf Khan
wrote:

On 7/1/2020 7:17 AM, John Doe wrote:
The servers' addresses?

That seems like a brute force approach, where you just store server
addresses of all servers of all VPN providers throughout the world.
Isn't there something more elegant they are doing, like deep packet
inspection?

I don't know what 'brute force' means in this context, but it's trivial to
script that lookup in two steps.
1. Perform a geoip lookup of the source IP. (One command, one argument)
2. Perform a comparison of that IP against known blocks of IPs. Part of the
key to speed being blocks of IPs rather than lists of individual IPs, but
either way works.

It's one lookup and one (or more) comparison(s). Very fast, very light
weight, very easy to implement.