A Tunnel Buys Topology, Not Encryption or Latency

The assumption is that a tunnel is a private, fast wire: you build one, and the traffic inside is encrypted, the path is shorter and the link behaves like a cable between two sites. Each part of that assumption is a separate property, and the tunnel delivers only the first thing you asked it for, which is a logical path. Everything else has to be chosen and configured on purpose. Confusing the properties is how a design ends up with an encrypted link nobody can troubleshoot and a latency promise no one can keep.

The myth: one tunnel, three guarantees

A tunnel does one thing reliably. It makes two endpoints that are not directly connected behave as if they were adjacent for some purpose, while the intervening network carries the outer packets. That is a topology change, and it is genuinely useful on its own.

Encryption, protocol carriage and forwarding isolation are separate decisions layered on top of it. A GRE tunnel has none of the three in the cryptographic sense, and an IP-in-IP tunnel is a valid design with no confidentiality at all. Neither of those is a mistake; they are tunnels doing exactly what tunnels do. The label on the diagram does not tell you which properties are present.

Once you separate the properties, the questions become answerable: does this tunnel carry a routing adjacency, does it carry frames, does it hide the inner addresses, does it promise anything about delay? Those are four different answers with four different configuration consequences.

What the tunnel actually adds to the map

The endpoints get a path they did not have before. Whether that path behaves like a routed hop or like an Ethernet segment depends entirely on the encapsulation, and the difference changes what the two sites can do with it. A routed tunnel gives you a next hop and a prefix; an Ethernet extension gives you broadcast behaviour and a much larger failure domain.

An IP tunnel does not automatically make the far site part of the same subnet, and it does not make a routing protocol run across it unless the implementation supports that adjacency. Multicast is another separate question with its own answer.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Those commands answer different parts of the question. The first tells you what kind of interface exists, the second tells you which path the kernel would choose, and the last two show the underlay's actual behaviour rather than the label's promise.

Carriage is a separate decision from reachability

A tunnel can carry a protocol the underlay does not forward. IPv6 over an IPv4 path is the classic case, and it works because the endpoints understand both families while the routers between them only need to deliver the outer packets. The underlay needs a working path to the tunnel endpoint and nothing more.

The endpoints, however, need full support: forwarding, addresses, and an application that actually uses the inner family. Assigning an IPv6 prefix to a tunnel does not make an IPv4-only service reachable over IPv6, and it does not make the underlay dual-stack.

Frame carriage is a bigger commitment than protocol carriage. Extending a broadcast domain across a tunnel moves spanning-tree behaviour, ARP and failure propagation with it, which is a design decision rather than a feature toggle.

Isolation is not confidentiality

Provider VPNs keep customer routes and traffic in separate forwarding contexts, and that separation is real and valuable. It is not encryption. The BGP/MPLS VPN specification is explicit that its privacy comes from the forwarding model rather than from cryptography, which is exactly the distinction that gets lost in a slide that just says VPN.

If you need confidentiality, you need a cryptographic mechanism with authentication and key management, and you need to know where it terminates. A tunnel that provides separation and a tunnel that provides encryption can be the same tunnel, but only when someone configured both.

The practical consequence is that "it is in a VPN" answers a question about routing context and tells you nothing about who can read the bytes on the path. Two teams can both be correct and still be describing different things. When the security question comes up, ask where the crypto terminates and what authenticates the peers, not whether a tunnel exists.

Latency and QoS follow the underlay

A logical edge is not a shorter physical path. The outer packets still traverse the same links, queues and providers, and encapsulation adds per-packet overhead plus processing at both ends. A tunnel can be fast because the underlay is good, never because it is a tunnel.

Quality-of-service treatment is worse than that, because it depends on administrative domains you may not control. Inner markings have to be mapped to outer markings deliberately, and every provider on the path has to offer the treatment you expect. Encryption does not create priority; it hides the field a middlebox might have used to classify the flow.

Measure the underlay before you promise anything. A report that shows stable delay and no loss on the outer path is evidence; a diagram with a tunnel on it is not.

Choose the tunnel for the network relationship you need, then specify encryption, access policy, packet size and performance separately. Four decisions, four pieces of evidence, and no single label standing in for any of them.