Re: [PLUG] VPN Recommendation Wanted

On Sun, Aug 3, 2025 at 6:52 AM Rich Freeman via plug <plug@lists.phillylinux.org> wrote:

On 8/3/2025 1:14 AM, brent saner via plug wrote:
> On Sat, Aug 2, 2025 at 10:45 PM Matt Mossholder <matt@mossholder.com>
> wrote:
>
> I'm not seeing anything in that RFC that supports what I think
> your position is. It sounds like your point is that a VPN is full
> mesh, while a tunnel is point-to-point, but that isn't stated
> anywhere in the RFC you provided.
>
> virtual private network (VPN)
>
> (I) A restricted-use, logical (i.e., artificial or simulated)
> computer network that is constructed from the system resources of
> a relatively public, physical (i.e., real) network (e.g., the
> Internet), often by using encryption (located at hosts or
> gateways), and often by tunneling links of the virtual network
> across the real network. (See: tunnel.)
>
> Tutorial: A VPN is generally less expensive to build and operate
> than a dedicated real network, because the virtual network shares
> the cost of system resources with other users of the underlying
> real network. For example, if a corporation has LANs at several
> different sites, each connected to the Internet by a firewall, the
> corporation could create a VPN by using encrypted tunnels to
> connect from firewall to firewall across the Internet.
>
>
> This definition says (to me) that a VPN has at least two
> endpoints, and -can- have more, but doesn't require more than 2
> nodes. Effectively, I take it as a VPN is an aggregation of one
> or more links, which are almost always encrypted (Please ignore
> the telcos that try to tell you unencrypted links like MPLS are
> VPNs. That is just them trying to co-opt the term)
>
>
> You're halfway there. (Worth noting that encryption itself isn't
> strictly necessary to meet the IETF definition; "often" not "always".)
>
> / $ virtual private network (VPN)
>    (I) A restricted-use, logical (i.e., artificial or simulated)
>    computer *network* that is constructed from the system
> resources of
>    a relatively public, physical (i.e., real) network (e.g., the
>    Internet), often by using encryption (located at hosts or
> *gateways*), and often by tunneling *links* of the virtual network
>    across the real network. (See: tunnel.)
>
>    Tutorial: A VPN is generally less expensive to build and operate
>    than a dedicated real network, because the virtual network
> shares
>    the cost of system resources with other users of the underlying
>    real network. For example, if a corporation has LANs at *several
>    different sites*, each connected to the Internet by a
> firewall, the
>    corporation could create a VPN by using encrypted *tunnels* to
> /
> / connect from firewall to firewall across the Internet. /
>
>
> Note the frequent use of pluralization, and the explicit mention of
> gateway(s) in the added emphasis.

IMO this is all needlessly pedantic as it is pretty common to implement
VPNs for entire networks at the gateway level and tunnel them over
wireguard.

However, your argument has a fatal flaw and I'll go ahead and point it
out as you seem to be REALLY putting a lot of weight on this definition.

First, let me edit that definition, ONLY removing the clauses that say
"often" as they are not the essential part of the definition:

/$ virtual private network (VPN)
   (I) A restricted-use, logical (i.e., artificial or simulated)
   computer *network* that is constructed from the system resources of
   a relatively public, physical (i.e., real) network (e.g., the
   Internet).
/

There is no mention of gateways - just a *network*/. /So, what is a network?

$ network
(I) An information system comprised of a collection of
interconnected nodes. (See: computer network.)
$ computer network
(I) A collection of host computers together with the subnetwork or
internetwork through which they can exchange data.

Usage: This definition is intended to cover systems of all sizes
and types, ranging from the complex Internet to*a simple system composed of a personal computer dialing in as a remote
terminal of another computer*.

So, a P2P connection between two hosts is a computer network. Two nodes
makes up a collection of interconnected nodes (sadly the IETF didn't
define "collection" but I think most would agree that a collection of
"computers" could contain just two computers). The P2P connection is a
network, and a VPN is just a type of network.

Yes, VPNs usually involve more than two nodes, just as networks usually
involve more than two nodes, but this is not essential to the
definition. The bit about gateways is embedded in an "often" clause,
and further it is mostly focused on the location where the encryption
tends to be implemented, but this is in no way essential to its
operation. Or at least, that's how the IETF defines the term here.

In any case I think this largely is tangential to the original question
of a provider. There are lists of them online with various attributes
that you can filter to find one that meets your requirements. The best
choice probably depends on why you're using one in the first place. If
you just want to avoid a nosy ISP then basically any will work. If you
want to avoid a nosy person at the other end of the connection who has
access to subpoenas then you'll have to make due with unverifiable
attestations to guide your choice. If you want to avoid the NSA just
give up now. If you want to play the whack-a-mole game with geofencing
then I'd suggest a large provider who can afford to play such games, and
where their large size suggests that their customers are probably
satisfied with their ability to do so.

As somebody else already pointed out, tor is a pretty good alternative.
In my experience it is MUCH more likely to get blocked than a VPN
though, and definitely not suitable for media streaming.

--

--
Rich

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug