Martin,

Well, it looks backwards to me. Here is the output from the trace route
command with VPN disconnected. I recognize my IP address (blotted out):

traceroute to libelle-systems.com (3.33.152.147), 64 hops max
1 xxx.xx.xx.xx 1.283ms 0.903ms 1.207ms
2 67.42.200.51 26.118ms 26.358ms 25.863ms
3 67.42.136.97 26.088ms 25.866ms 25.687ms
4 99.82.183.2 33.994ms 32.938ms 33.157ms
5 52.93.74.36 34.406ms 33.729ms 33.717ms

And here it is with the VPN connected:

traceroute to libelle-systems.com (3.33.152.147), 64 hops max
1 10.5.0.1 32.298ms 32.149ms 32.618ms
2 83.136.182.3 32.116ms 32.825ms 32.225ms
3 62.115.186.14 32.947ms 32.936ms 33.037ms
4 213.248.75.245 32.402ms 32.706ms 32.261ms
5 209.120.154.162 50.908ms 51.963ms 51.644ms
6 150.222.206.215 52.287ms 52.505ms 52.384ms

Can you explain this?

Dan
5J

On 1/28/23 16:21, Martin Gregorie wrote:
> traceroute libelle-systems.com

Bravely going well off thread to answer David's questions...

VPN's are in most cases snake oil - they typically purport to increase your security through 'encryption', but in reality they just move the unencrypted bit from your computer to some random unaccountable server in a far-off land. In general I cannot recommend them.
You may also get worse service from websites unable to geolocate you correctly (i.e. SkySight, to put the location dot).

So we go from;
Your Computer <--unencrypted, if not using SSL i.e. padlock symbol--> Your destination

And instead get;
Your Computer <--encrypted--> Unaccountable Server <--unencrypted, if not using SSL i.e. padlock symbol--> Your destination

Adding this extra stop at Unaccountable Server almost always adds distance/latency and the resulting 'speed' as it appears to the end user will be lower.

There are a few circumstances where this is not the case. Your data doesn't necessarily flow along the fastest possible path from A to B, more typically it flows across the most economical path/'peering' for your ISP. This is often but not always the fastest.

If your VPN provider is colocated at or at a location your ISP has fast connectivity to, and your VPN provider also pays for fast connectivity from itself to your destination, it could be faster. Cloudflare WARP+ for example puts servers with most ISP's, and then (claims to) pay a premium for peering faster than your ISP might be paying.

I tested this to be true in Cloudflare's case but also found a small number of websites that broke and bugs/crashes in the Cloudflare software that lead to inexplicable network dropouts.

In summary, the security claims are largely a scam, and you're more likely to see better performance from choosing a more expensive/reputable ISP that pays more for faster paths/peering. If you don't have a choice of ISP and it solves a problem for you, do what you have to do...

On Sunday, January 29, 2023 at 12:54:36 PM UTC+12, Dan Marotta wrote:
> Martin,
>
> Well, it looks backwards to me. Here is the output from the trace route
> command with VPN disconnected. I recognize my IP address (blotted out):
>
>
> traceroute to libelle-systems.com (3.33.152.147), 64 hops max
> 1 xxx.xx.xx.xx 1.283ms 0.903ms 1.207ms
> 2 67.42.200.51 26.118ms 26.358ms 25.863ms
> 3 67.42.136.97 26.088ms 25.866ms 25.687ms
> 4 99.82.183.2 33.994ms 32.938ms 33.157ms
> 5 52.93.74.36 34.406ms 33.729ms 33.717ms
>
> And here it is with the VPN connected:
>
> traceroute to libelle-systems.com (3.33.152.147), 64 hops max
> 1 10.5.0.1 32.298ms 32.149ms 32.618ms
> 2 83.136.182.3 32.116ms 32.825ms 32.225ms
> 3 62.115.186.14 32.947ms 32.936ms 33.037ms
> 4 213.248.75.245 32.402ms 32.706ms 32.261ms
> 5 209.120.154.162 50.908ms 51.963ms 51.644ms
> 6 150.222.206.215 52.287ms 52.505ms 52.384ms
>
> Can you explain this?
>
> Dan
> 5J
>
> On 1/28/23 16:21, Martin Gregorie wrote:
> > traceroute libelle-systems.com

On Sat, 28 Jan 2023 17:54:32 -0700, Dan Marotta wrote:

> Martin,
>
> Well, it looks backwards to me. Here is the output from the trace route
> command with VPN disconnected. I recognize my IP address (blotted out):
>
>
> traceroute to libelle-systems.com (3.33.152.147), 64 hops max
> 1 xxx.xx.xx.xx 1.283ms 0.903ms 1.207ms 2 67.42.200.51
> 26.118ms 26.358ms 25.863ms 3 67.42.136.97 26.088ms 25.866ms
> 25.687ms 4 99.82.183.2 33.994ms 32.938ms 33.157ms 5
> 52.93.74.36 34.406ms 33.729ms 33.717ms
>
> And here it is with the VPN connected:
>
> traceroute to libelle-systems.com (3.33.152.147), 64 hops max
> 1 10.5.0.1 32.298ms 32.149ms 32.618ms 2 83.136.182.3 32.116ms
> 32.825ms 32.225ms 3 62.115.186.14 32.947ms 32.936ms 33.037ms 4
> 213.248.75.245 32.402ms 32.706ms 32.261ms 5 209.120.154.162
> 50.908ms 51.963ms 51.644ms 6 150.222.206.215 52.287ms 52.505ms
> 52.384ms
>
> Can you explain this?
>
What Matthew said, but also note that there's nothing in the way the
Internet works that says that your laptop and your TV dongle have to
connect to the same box at the end of the first hop to end outside your
house: the device that connects stuff inside your house to the the
physical external network, commonly referred to as being or containing a
firewall, is itself a router and, while it may have been configured to
talk to your ISP, there's nothing to say that something else in your house
(such as a TV dongle) can't tell it to connect elsewhere, such as to a
VPN. The only restriction it *should* have is to refuse redirection
requests from outside (though some el-cheapo units will accept them).

FWIW I have my house's gateway router configured to be invisible from the
outside.

--

Martin | martin at
Gregorie | gregorie dot org

On Friday, January 27, 2023 at 4:52:44 PM UTC-7, Martin Gregorie wrote:
> On Fri, 27 Jan 2023 13:04:05 -0700, Dan Marotta wrote:
>
> > I'm not up on VPN technology but the vendor, NordVPN, in my case says
> > that they bypass my ISP's servers altogether. I can't see how they
> > could do that, since my ISP connects the wire to my house, which
> > connects to a fiber in the service box in the neighborhood, which I
> > would assume, connects to their servers.
> >
> Interesting.
>
> Does the path a packet takes to reach a target destination from your
> laptop, differ depending on whether VPN is on or off?
>
> It would be worthwhile to see if 'traceroute' shows ant differences: it is
> a toool that shows the route a probe message sent by it takes across
> t'interwebs, so sending the probe to the same destination with VPN on and
> then off should clearly show whether the path the probe message takes
> depends on the VPN setting, and *may* also show time-of-flight
> differences (provided they don't just get lost in Internet traffic queues,
> and switching delays).
>
>
>
>
>
> --
>
> Martin | martin at
> Gregorie | gregorie dot org
There have been instances (and apparently still are) where specific services were being throttled at edge routers and VPN tunnels were able to improve performance substantially. I haven't done much testing recently but my VPN service with a static IP attached seems to be rate limited to 50Mbps for the servers I connect with. Haven't tested other portals with dynamic IP's, but may have to do that.

Frank