They are all doing "deep packet inspection" now to try to detect tethering cheaters, among other things. This means that they have their computers doing both "NAT" (address translation) and also inspecting each packet robotically before passing it on.
I don't know of any data confirming the claim that wireless carriers are routinely running full DPI on every packet transiting their networks. That's both computationally expensive, and would need extensive bureaucratic configuration to even know what sort of things are being tagged/flagged/filtered. Plus, at least in the USA, utilizing DPI at such a massive scale would - in theory, at least - run afoul of wiretapping statutes (as to whether they'd ever be enforced or not, a different and more complex question). That level of reading of electronic communications is supposed to require a judicial warrant (although the NSA doesn't think so, nor quite often the FBI, and so on...).
Wireless carriers aren't really using NAT, not that I've ever heard of. Indeed, NAT is really not even close to suited for wholesale-class network traffic levels.
NAT is a hack, basically, designed for small stuff like routers and mostly used in "edge of network" scenarios ("Network Address Translation allows a single device, such as a router, to act as an agent between the Internet (or "public network") and a local (or "private") network. This means that only a single, unique IP address is required to represent an entire group of computers."). It's finicky, not terribly reliable, and certainly not something that is used in wholesale backhaul scenarios. They certainly engage in network management practices that are somewhat equivalent, in functional terms, to "NATting" - ensuring ports are mapped through network topology, basically.
VPNs encapsulate your traffic in an encrypted container, then strip that on the other end.
Most everyone - myself included - talks about "encapsulation" as something that's done by VPNs. But they don't encapsulate anything. Encapsulation is actually one of the four attributes of
object oriented programming (those four being: Data Abstraction, Encapsulation, Polymorphism, Inheritance... and sometimes fifth ones are tacked on, or not). It's summarized as follows:
"In object-oriented programming, objects interact with each other by messages. The only thing that an object knows about another object is the object's interface. Each object's data and logic is hidden from other objects. In other words, the interface encapsulates the object's code and data."
But VPNs don't do anything like this. Indeed, the entire idea of a "tunnel" - which we all use when discussing VPNs - is something of a misnomer. There's no "tunnel," and nothing is "inside" of anything else in tactical terms. We're using the words in a
conceptual sense - something akin to the distinction between the
logical topology of a network and the
physical topology. They are quite different.
VPNs generally re-packetize data. There is no "wrapper" - there's just packet headers, and packet payload. Nothing is "encapsulated" inside anything else. True, there's cryptographic hanky-panky going on... but it's not inside anything, nor outside anything. It's just encryption.
The problem is, when we start taking concepts like encapsulation and tunnels seriously as descriptions of what's happening with VPN connections, we make all sorts of goofy assumptions about how things are operating - and these assumptions breed further errors. That's not to say that we need to banish these words from our vocabulary - only that we need to be aware they are being used in a purely
metaphorical sense. Not as descriptors of actual reality.
Enter IKE. V1 was faster that LT2P and PPTP but still had security issues in many circumstances. IKEv2, on the other hand, is fast, uses IPSEC (a formal IP extension for encapsulating packets securely) and a wide variety of authentication options including shared secrets ("passwords"), secure certificates (public-key) or both.
Alas, IKEv2 is also subject to the same sorts of
well-documented MiTM attacks that are found in the wild when dealing with other flavours of VPN connections - preying on the need for Diffie Hellman-enabled crypto handshake procedures to exchange authentication data within the same channel as communications travels (shared certificates obviate this by making use of
parallel channel authentication, without usually stating that in those terms).
And IPsec really doesn't have anything to do with "encapsulating packets securely." It can do that, or enable that to be done... but it also doesn't necessarily do that. Basically, it's a big crypto toolset:
"IPsec is a suite of protocols for securing network connections." Which is not the same thing as "encapsulating packets" (which, as we we discussed above, isn't really encapsulation nor anything like it), not at all.
There is a price for this, in that the IPSEC server must have a fast connection to the Internet itself, and for bulk file transfers this will slow things down, because the data flows over that link twice in getting to you on the phone -- once in and once out. If you run a "Speedtest" over the VPN it'll be about half the speed of the raw connection
No, this isn't right at all.
Yes, if you're pulling data through a VPN "gateway" then those data go into and then out of the server - definitionally so, if you think about it for a minute. Where
else would those data go? The data can't just magically jump from the server to someplace else - it goes across the NIC.
But this doesn't have anything to do with slowing down data, in any formal sense. Most servers have at least a 100 megabit link to the colo where they live, and nowadays gigabit is all but baseline (that's giga
bit not giga
byte - sometimes referred to as "small b (bit) versus big B (btye)" - with one byte being composed of 8 bits, so a gigabit connection is going to be 1/8th the capacity of a gigabyte connection). So if you're pulling a file through a VPN network gateway with a gigabit connection, even if you've got a 100 megabit connection (that actually works at that speed) from your ISP, you're not going to hit that gigabit capacity limit or anything close to it (unless the VPN company has badly oversold the network, or whatever).
And besides, when we talk about a "gigabit connection" for a server hosted at a colo someplace, we're taking about a gigabit uplink
and downlink - they're measured differently, and the NIC handles each differently. (don't ask me about the physical layer explanation - I have no idea, although I'd love to learn if someone wants to post up such information). So, in theory anyway, the server can be sending a gigabit "up" through the NIC simultaneously as a gig is coming "down" via the NIC into the server. All pretty routine, right?
It only goes weird when that gets conflated into an explanation for slow VPN connections - which have nothing to do with servers seeing traffic coming and going during routine VPN network topologies. Slow VPN performance is a more complex issue, and is far more often due to crappy configuration and poor network/server administration than with any hocus-pocus about server network interconnections.
Hand-waving mis-explanations of poor VPN performance have two bad consequences:
- First, it makes it seem like the word "VPN" magically makes stuff slow - which is utter nonsense in technical terms.
Second, it takes the focus away from the real reason most VPN networks and services are slow: bad management, bad configurations, and bad decisions about how to run things. That's a far cry from some kind of profound technological limitations.
Now, the author of the article I've nitpicked here is not a technologist - he's (afaik) some sort of equities analyst. He's simply picked up these misunderstandings from elsewhere, and indeed they're all over the place once you start looking. Thus I want to re-emphasize that I don't want to be perceived as picking on him - overall he does a rather good job of making sense of some bits and pieces of VPN technology - far better than I'd do trying to explain
his line of work!
As we continue this thread, we'll look to dig deeper and find examples of VPN misinformation that emanate from people who really should know better. That's where the problems really start, and it's where we need to look as we work towards putting discussions of VPN technology back on a sound footing.
Cheers,
