Restoring the Boundary: Defences for Open Tunnel Hosts

Defending an open tunnelling host means restoring the decisions that arbitrary decapsulation has removed. The focus here is not a universal hardening checklist, but a comparison of controls against the specific paths already identified: one-way forwarding, NAT-state manipulation, two-way reply delivery, and GRETAP access to a private LAN. The practical goal is to choose controls that close the relevant boundary while recognizing the costs of strict source validation, multipoint connectivity, and Layer 2 requirements.

A single setting cannot address all four paths. Peer authentication can stop an arbitrary sender before decapsulation, but an authorized tunnel can still carry an unsafe inner packet if forwarding is unrestricted. Reverse-path filtering can block one NAT-state transition, but it may disrupt asymmetric routing and does not by itself contain every Layer 2 behavior. Dropping broadcasts can reduce GRETAP exposure, but it does not authorize the remaining unicast frames. Good defense follows the mechanism.

Close the peer gap before tuning symptoms

The strongest control is to ensure that the endpoint has a real trust relationship with the remote peer. The paper recommends using more secure tunnelling protocols such as the IPsec suite, which incorporates authentication and encryption. This addresses two weaknesses in the studied configurations: the endpoint is not relying on an unauthenticated packet format to identify a peer, and the traffic between the endpoints receives security properties that bare IPIP or GRE do not provide by default.

A secure underlay is especially relevant when the application needs the reachability of a Layer 2 tunnel. The paper suggests using IPsec together with GRETAP when Ethernet-frame encapsulation is required. That combination does not make every bridge policy safe automatically. It protects the relationship between authorized endpoints, while the bridge still needs an explicit decision about which frames, broadcasts, and private interfaces should be connected.

Peer authorization is the more fundamental boundary. An endpoint should not decapsulate packets from any source merely because the outer packet has the correct protocol and destination. If the legitimate peers are known, the host should allow those peers explicitly. The paper proposes a set or subnet of trusted remote addresses for multipoint use, with re-encapsulation limited to traffic from those trusted sources. This preserves a multipoint design without treating the entire Internet as a possible tunnel peer.

The authors offer a conjecture about why open configurations may be common: Linux may not support allowlisting multiple remote tunnel addresses in the way users need for multipoint tunnels, making an unspecified remote address a convenient workaround. That explanation is not a measured root cause, and it should not be used to excuse the configuration. It does identify a migration problem. If the intended design really is multipoint, “turn off the tunnel” may be unrealistic; the safer replacement must express the actual peer set or trusted address range.

A firewall remains useful, but its position matters. RFC 2784 notes that packet filtering may need to inspect inside a GRE packet or terminate the tunnel at the firewall. Filtering only the outer public address answers whether the encapsulated object may reach the host. It may not answer whether the inner source, destination, protocol, or broadcast behavior should be released. The control must follow the packet across decapsulation, not stop at the first header.