D3-ET Encrypted Tunnels: Isolating Internal Traffic in Transit and Verifying It

Internal traffic that crosses networks you do not fully control, such as the internet, a carrier link or a shared data centre fabric, can be read or altered by anyone positioned on the path unless it is wrapped in an encrypted tunnel. MITRE D3FEND names this countermeasure Encrypted Tunnels (D3-ET) and defines it as "Encrypted encapsulation of routable network traffic." It sits under the Isolate tactic as a child of Network Isolation (D3-NI), and D3FEND models it as isolating the Intranet Network artefact. D3FEND's entry is short: a definition, one artefact and one reference, the original IETF Security Architecture for the Internet Protocol. This card turns that into practice: the tunnel families in use, what a tunnel isolates and what it does not, how to prove a tunnel is really carrying the traffic it should, and where tunnels fail. It is written for network and infrastructure engineers; protocol depth is in the IPsec Security Guide and the WireGuard Security Guide.

Key takeaways

• Encapsulation plus encryption. The defining property is that whole routable packets are wrapped and encrypted between two endpoints, so the path in between sees only the outer header.
• No ATT&CK mapping in D3FEND. D3FEND 1.6.0 lists no ATT&CK techniques for D3-ET, directly or by inference (checked November 2026). Any threat mapping on this page is NHI Mgmt Group's view and labelled as such.
• Policy decides what is protected. In IPsec the Security Policy Database marks each packet PROTECT, BYPASS or DISCARD; a missing selector silently sends traffic in clear.
• A tunnel is not access control. It protects traffic between endpoints; it does not decide which users or workloads may reach which services once inside.
• Attackers tunnel too. The same encapsulation hides command and control, which is why allowed tunnel endpoints and protocols need an inventory and egress control.

D3-ET at a glance

How it works

D3FEND's reference is the first IETF IPsec architecture, RFC 1825. That document is obsolete: RFC 2401 replaced it and RFC 4301, a Proposed Standard from December 2005, replaced RFC 2401. The current architecture describes the elements every encrypted tunnel needs, whatever the protocol.

• Tunnel mode encapsulation: RFC 4301 tunnel mode applies protection to a whole tunnelled IP packet, adding an outer header for the tunnel endpoints and keeping the inner header for the original source and destination. Security gateways must support tunnel mode, and RFC 4301 says that when either end of a security association is a gateway, the association should generally be tunnel mode.
• Confidentiality and integrity: ESP is mandatory and provides confidentiality, integrity and authentication; RFC 4301 states ESP with encryption but no integrity is not recommended.
• Policy: the Security Policy Database is an ordered list of rules that gives each packet a disposition of PROTECT, BYPASS or DISCARD, and RFC 4301 recommends a final catch-all rule that discards unmatched traffic.
• Keys: IKEv2 (RFC 7296, an Internet Standard, STD 79) negotiates keys and security associations over UDP 500, or UDP 4500 when NAT traversal encapsulation is needed.

Other tunnel families implement the same idea with different designs. WireGuard sends all traffic over UDP, uses Curve25519, ChaCha20-Poly1305 and BLAKE2s, rekeys every few minutes for forward secrecy, and does not respond to unauthenticated packets. TLS-based VPNs carry traffic inside a TLS session, which traverses restrictive networks more easily. NIST SP 800-77 Rev. 1, Guide to IPsec VPNs, covers IPsec deployment and describes alternatives and when each fits.

Tunnel options compared

Protocol choice in more depth: VPN Protocols Compared: WireGuard, IPsec, OpenVPN.

Threats it addresses (NHI Mgmt Group view)

Because D3FEND gives no ATT&CK mapping for D3-ET, the table below is our own analysis of where encrypting internal traffic in transit changes an attacker's options. It is not D3FEND data. IDs were checked against ATT&CK v20.

Mitigation guidance for the same ground is in M1041 Encrypt Sensitive Information.

Where identity fits

Every tunnel endpoint is a machine identity. IPsec gateways authenticate with certificates or pre-shared keys, and WireGuard peers are identified by their public keys. A pre-shared key reused across many sites, or a private key copied into configuration backups, lets anyone holding it impersonate a gateway. Treat tunnel keys and certificates as managed non-human credentials: inventory them, store them in a secrets manager or hardware, rotate them and revoke them when a device is retired. The authentication options are compared in the IPsec Security Guide.

Implementation steps

1. Map the flows that cross untrusted paths. List site-to-site links, cloud interconnects, remote access and server-to-server traffic between data centres. Record what each flow carries and whether it is already encrypted end to end at the application layer (for example with TLS or mTLS).
2. Choose the tunnel family per flow. Use the comparison above; standardise on as few families as possible so monitoring and key management stay manageable.
3. Set a cryptographic baseline. Allow only current algorithms and IKEv2, remove legacy proposals, and prefer certificate authentication to shared keys. NIST SP 800-77 Rev. 1 is the reference for IPsec.
4. Write deny-by-default tunnel policy. In IPsec, define PROTECT selectors for every protected flow and finish with a DISCARD catch-all, as RFC 4301 recommends; in WireGuard, restrict each peer's allowed address ranges to what it needs.
5. Pilot one link with a fallback. Bring up the new tunnel alongside the existing path, move a test subnet, verify (next section), then cut over. Keep the old configuration to roll back.
6. Put key lifecycle in place. Certificate expiry alerts, rotation schedules and revocation for decommissioned devices.

How to verify it works

• Packet capture on the transit side: capture on the outside interface of a gateway during a test transfer and confirm only ESP, UDP 500/4500 or the WireGuard UDP port appears, with no clear-text inner protocols.
• Policy leak test: send traffic to a destination that should be tunnelled but is outside the configured selectors and confirm it is dropped, not sent in clear.
• Tunnel-down test: take the tunnel down in a maintenance window and confirm protected traffic stops rather than falling back to an unencrypted route.
• Configuration review: confirm negotiated algorithms on live security associations match the baseline, not just the configured preference list.
• Key inventory check: reconcile tunnel credentials against the asset inventory and flag keys belonging to retired devices.

Limits and bypasses

• Only the path is protected: traffic is clear on the networks at each end; a compromised endpoint reads everything that passes through it.
• BYPASS and split tunnelling: traffic outside policy or excluded by split tunnel rules travels unprotected.
• Flat networks behind the tunnel: a tunnel joins two networks; without segmentation, a compromised host at one end reaches the whole of the other. See the Network Segmentation Guide.
• Attacker-built tunnels: adversaries use encrypted channels and protocol tunnelling for command and control (T1573 Encrypted Channel, T1572 Protocol Tunneling). Encryption is neutral; egress filtering decides which tunnels may leave. See the T1572 Protocol Tunnelling Defensive Guide and D3-OTF Outbound Traffic Filtering.
• Exposed tunnel gateways: the gateway itself is an internet-facing service; keep it patched with vendor security updates and limit its management interfaces.

Common failure patterns

• Missing catch-all discard: new subnets are added without selectors and their traffic leaves in clear.
• One pre-shared key everywhere: a single leaked key compromises every site.
• Legacy proposals kept for one old peer: weak algorithms stay enabled for all peers.
• Tunnel treated as trust: anything arriving through the tunnel is allowed to anything, so a branch compromise becomes a data centre compromise.
• Unmonitored certificate expiry: a link drops, and the emergency fix is a temporary unencrypted route that stays.

Framework mapping

Related countermeasures

• Network Isolation (D3-NI): the parent family, which also includes traffic filtering techniques such as D3-NTF Network Traffic Filtering and D3-ITF Inbound Traffic Filtering.
• Outbound Traffic Filtering (D3-OTF): controls which tunnels may leave the network.
• Mutual TLS: application-layer encryption between services, often used instead of or inside network tunnels. See the mTLS Guide.

Practitioner checklist

• Inventory every flow that crosses a network you do not control and how it is encrypted.
• Standardise on IKEv2 or WireGuard for network tunnels and remove legacy protocols.
• End IPsec policy with a DISCARD catch-all and restrict each WireGuard peer's allowed ranges.
• Authenticate tunnel endpoints with certificates or per-peer keys, never one shared key.
• Manage tunnel keys and certificates as machine identities with rotation and revocation.
• Verify with transit-side packet capture and a tunnel-down test after every change.
• Segment and filter traffic arriving through tunnels; do not treat the tunnel as trust.
• Monitor egress for unexpected tunnel endpoints.

Standards and references

• MITRE D3FEND: Encrypted Tunnels (D3-ET)
• IETF: RFC 4301 Security Architecture for the Internet Protocol
• IETF: RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2)
• IETF: RFC 1825 Security Architecture for the Internet Protocol (obsoleted)
• NIST: SP 800-77 Rev. 1 Guide to IPsec VPNs
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-8)
• WireGuard: Protocol and Cryptography

Related NHI Mgmt Group resources: IPsec Security Guide · WireGuard Security Guide · How VPNs Work · Network Segmentation Guide · MITRE D3FEND Guide