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 toconnect from firewall to firewall across the Internet.
Note the frequent use of pluralization, and the explicit mention of gateway(s) in the added emphasis.
(Now, that *link* can be virtual/abstract, such as in WireGuard, IPsec, etc....)
You can certainly TREAT a peer as a gateway to another network, but that's now doing host-internal interface routing/forwarding - and each peer needs to know about that route. You need to cross network boundaries simply to reach any given third node unless you peer with that third node directly.
(To use the L1 equivalent: you absolutely can use a crossover link to get to another network. But that host is now forwarding on a different net for its peer to reach any other host through it. It never leaves the net for a VPN.)
Things like TailScale obscure/abstract that, but that's what it's doing - adding explicit routing information for other peers that it gets from an additional informational service. It "feels" like a VPN, but it's still peer-to-peer - it's just automating a lot of the peering setup.
It behaves as a more traditional network and has a client/server model, with the server acting as a centralized authority for AAA, a "virtual switch", and an inherent gateway to other networks (access to which may or may not be allowed, depending on route filtering, firewall rules/policy, etc. on the VPN server).
A can get to D without direct connection to D via the server. C can connect to B without peering directly with it.
A does not need to go through B to get to C. A does not need to add a route using B as a gateway to get to C.
The VPN server, of course, can prevent access from A to C via firewall policy and rules, but access to other nodes is implicit.
In a peered tunnel, A cannot reach C, even if they both peer with B, unless explicit routing/firewalling/forwarding rules are in place on B, A, and C
OR
A peers directly with C.
The former has now crossed links. They are no longer "on-link"; A uses B to get to C and vice versa.
The latter is... again, a peering. It's explicitly configured on both ends.
There is no centralized packet forwarding as in a VPN, there is no network because the only way to accomplish any given communication between (A|B|C|D) is via A↔B, A↔C, A↔D, B↔C, B↔D, C↔D. Access to other nodes is explicit.
These are fundamentally different topologies.
That's why things like TailScale are so popular- because people do not like manually setting up multiple peers, and because they do not like manually adding routes. They want a managed service so they can cross-communicate with multiple nodes simultaneously.
When instead, of course, they could just... use a VPN. Which is... managed. By nature. But I digress.
Similarly,
It sounds like your point is that a VPN is full mesh
Yes and no. "Mesh" is an overloaded term; when I hear it, I think of things like Babel or B.A.T.M.A.N.(-Adv), IS-IS, etc. or even e.g. 802.11s, where each node is a potential hop. That's not my intended distinction, though that doesn't mean your usage of the word is wrong - again, it's an overloaded term. It means a lot of different things. I'm probably too old.
What I simply mean is a VPN is topographical and centralized, whereas peered tunnels (e.g. WireGuard) are flat and directly connected to nodes (or you explicitly fudge the network using out-of-service implementation). A network ceases to be the same network when it crosses a network boundary; that has now routed/forwarded to a different network. Peers' boundary is "the other host".
(This of course all gets confusing quickly, because for instance OpenVPN does support a peered mode, which acts closer to e.g. IPsec, WireGuard, and ilk, but it's not the common setup.)