Tunnel Technology Comparison

Tunneling encapsulates one communication protocol within another. Selection begins by answering "what exactly needs to be transported": an unmodifiable Ethernet frame, an entire subnet's IP packets, or a single TCP connection for a specific service. These requirements differ in broadcast scope, routing behavior, and permission boundaries; they cannot be ranked solely by product performance.

"Deployability" also considers whether existing devices support it, whether operations can manage keys and routing, and whether the egress allows the required transport. Device support for IPsec offload does not prove that specific algorithms, encapsulation, and traffic are actually using the offload path.

IPIP and GRE: The Simplest IP Encapsulation Is Not the Same Protocol

IPv4-in-IPv4 directly adds a new IPv4 header before the original IPv4 packet, with the outer Protocol field set to 4; without options, this adds 20 B. GRE uses protocol number 47, with an additional 4 B base GRE header, where the Protocol Type field indicates the encapsulated protocol. Therefore, GRE is more versatile, but it cannot be called "IPIP without extra headers." IP-in-IP RFC 2003, GRE RFC 2784

GRE can carry fields such as Key, Sequence Number, or Checksum via extensions; its length should not be fixed at 4 B. The Key can distinguish logical tunnels but cannot serve as an authentication credential; an attacker can construct the same Key without knowing any encryption private key. Basic IPIP and GRE do not provide confidentiality for the payload.

Assuming an inner 1400 B IPv4 packet: IPv4-in-IPv4 without options is 1420 B, and basic GRE over IPv4 is 1424 B. This excludes the outer Ethernet header and does not include encryption. When comparing this number to "bytes occupied online," you must align the measurement scope to the same layer.

VXLAN and Geneve: The Tunnel Itself Is Not a Complete Virtual Network Control Plane

VXLAN encapsulates inner Ethernet frames into UDP. The base VXLAN header is 8 B, and the VNI is 24 bits. The VNI represents a logical network, not an encryption key; mis-joining with the same VNI still requires underlying isolation and ingress validation. The UDP source port can provide traffic hashing information for outer ECMP, but this does not mean every packet should randomly change paths. VXLAN RFC 7348

Geneve's base header is also 8 B, supporting variable-length options, making it suitable for carrying network virtualization metadata; computational overhead must include the actual option length. When encountering critical options that cannot be understood, processing rules affect whether the packet can be received; options cannot be treated as transparent decorations for all endpoints. Geneve RFC 8926

Encapsulation only explains how packets are transported, not where the remote MAC is, who unknown unicast should be sent to, or how broadcast is replicated. Learning, static configuration, or control methods like EVPN handle these issues. Layer 2 extension spreads broadcast and failure impact to more locations; if the application only requires unicast IP communication, first determine if it truly relies on the same broadcast domain.

Why VXLAN Does Not Require MTU to Be Exactly 9000

Taking the example of no VLAN, inner frames without FCS, and outer IPv4 without options: a 1500 B inner IP packet plus 14 B inner Ethernet, 8 B VXLAN, 8 B UDP, and 20 B outer IP forms a 1550 B outer IP packet. The path needs to support this size; 9000 is just one possible network configuration. You can also lower the inner MTU, but you cannot treat arbitrary fragmentation as a cost-free remedy.

inner_ip = 1500
encapsulation = {
    'IPIP/IPv4': 20,
    'GRE-basic/IPv4': 20 + 4,
    'VXLAN/IPv4': 20 + 8 + 8 + 14,
    'VXLAN/IPv6': 40 + 8 + 8 + 14,
    'Geneve/IPv4+16B-options': 20 + 8 + 8 + 16 + 14,
}
assert inner_ip + encapsulation['VXLAN/IPv4'] == 1550
assert 1500 - encapsulation['VXLAN/IPv4'] == 1450
assert 1500 - encapsulation['VXLAN/IPv6'] == 1430
assert 1500 - encapsulation['Geneve/IPv4+16B-options'] == 1434
# 1550 B outer IP packet plus outer Ethernet header and FCS; preamble and frame gap not yet calculated.
assert 1550 + 14 + 4 == 1568
print('Encapsulation budget calculated uniformly by outer IP length passed')

Inner VLANs, additional encryption, or second-layer tunnels continue to consume budget. TCP MSS only affects TCP data segments; lowering MSS does not automatically solve large UDP datagrams, nor does it replace PMTU handling for all paths.

Can a 1500-byte Inner Packet Fit Inside?

First compare VXLAN's IPv4 and IPv6 outer layers; the inner limit differs by 20 B. Then select ESP; increasing the inner length from 1438 to 1439 does not increase the outer by just 1 B, but jumps from 1500 to 1504 due to alignment. The budget must account for such discrete changes.

WireGuard, IPsec, and Platform Capabilities Should Be Compared Separately

WireGuard combines peer public keys, AllowedIPs, and the UDP data plane; the protocol itself lacks a complete user directory or universal automatic hole-punching service. IPsec/IKEv2 protects IP traffic via policies and SAs, offering a richer configuration space for authentication, algorithm negotiation, and device interoperability. Performance is determined by implementation, algorithm acceleration, packet length, core count, and link; there is no fixed champion across environments.

Tailscale adds identity, policy distribution, discovery, and relaying on top of WireGuard. The difference between it and bare WireGuard is not just a single throughput test; when comparing deployment costs, you must account for the workload of manually maintaining peers, public keys, and routes, as well as the dependency on the platform control plane.

The endpoints of "end-to-end encryption" must be clearly defined: two business hosts terminating the tunnel themselves are different from a tunnel between two gateways. The latter can continue over plaintext networks after leaving the gateway; application TLS can provide protection one layer further.

Reverse Tunnel: Internal Client Initiates Outbound, Public End Receives Access

In standard public port forwarding schemes, the internal proxy C actively connects to the public proxy S, S forwards the external connection to C, and then C connects to the local service. This avoids the requirement for direct inbound access to the internal network, but the public S still needs to be reachable, and C's outbound must also be permitted. There is no need to successfully establish a UDP hole-punch from the visitor to the internal network here.

Common deployments of rathole and frp both have server/client roles; it is inaccurate to write that the former is naturally symmetric and decentralized while the latter is centralized. The current rathole repository configuration supports TCP and UDP services and provides transport options like TLS and Noise; claims of "TCP only, encryption relies on Caddy" are inaccurate. rathole project, Transport Configuration

Product support for UDP services is different from "proxy-to-proxy necessarily uses native UDP transport." If UDP data is carried over a reliable stream, packet loss and head-of-line blocking behaviors will change; if multiple service connections share a single TCP transport, outer packet loss recovery may affect other multiplexed connections. frp Network Configuration

Why Connection Pools Cannot Eliminate All Handshakes

A pool moves some connection preparation work to before the business request arrives, reducing wait time on hit; reuse allows multiple logical connections to share an existing transport. frp supports both mechanisms, so "rathole pre-builds, frp always creates new TCP per request" cannot be used as the fundamental difference between the two.

Even if the S—C channel is ready, the connection from the visitor to S, the connection from C to the local service, and the application TLS/login steps may still exist. When pooled connections become invalid, detection and replenishment are needed; early eof cannot be uniquely attributed to NAT idle timeout; it may also come from peer closure, process exit, or protocol mismatch.

For example, if a request requires establishing a channel on demand, adding an extra wait of 40 ms, and the prepared channel hit rate is 90%, the average wait for this item alone is 4 ms. The remaining 10% of requests still have a 40 ms wait; the average cannot be used to claim tail latency has disappeared. Larger pools also consume more FDs, memory, and gateway state.

Ingress TLS and Tunnel Encryption: Two Different Termination Points

If Caddy terminates browser TLS at S, S can see HTTP plaintext; enabling TLS/Noise for S—C can continue to protect the transport, but it does not turn S back into a relay that cannot see business content. If application TLS is passed through from the visitor to the origin, S only forwards the corresponding ciphertext, and the origin is responsible for certificates and application authentication.

The proxy registration token is used to prove that C has the right to register a specific forwarding service; it does not automatically verify every user accessing the public listening port. When exposing public management pages, database ports, or file services, access control needs to be implemented at the actual entry or application; providing a single token to both tunnel sides does not mean the service is privatized.

Making a Choice with a Complete Scenario

Assume you need to allow three colleagues to access the management page of a home NAS. Visitors can install clients, and public access is not required. First, compare the member authorization, client support, and recovery costs of device overlay network solutions; there is no need to first open the management page to the public network and then add extra ingress authentication.

If the goal changes to a public demo site that requires no client installation, a reverse HTTP proxy fits the ingress form better; next, determine the TLS endpoint, domain name, origin identity, and request size/timeout. If the goal changes to connecting two subnets with many IP services, then compare gateway VPN, routing, and return paths. If the application must rely on Layer 2 discovery or specific Ethernet semantics, then continue to evaluate Layer 2 overlay networks and broadcast boundaries.

These judgments are not a permanent product ranking. An evaluation report should at least provide: who the data actually passes through, who can decrypt it, what is allowed to be accessed, the maximum effective packet length, memory usage and tail latency under full load, and how new and old services behave after control connection interruption. Writing only "lightweight, low latency, enterprise-grade" does not allow for reproduction or trade-off decisions.