Securing Multi-Cloud DCI: Implementing Layer 2 Line-Rate Encryption with MACsec Between Hetzner and Vultr

Introduction: The Imperative of Data Center Interconnect (DCI) Security

In modern enterprise infrastructure design, multi-cloud and hybrid-cloud strategies have shifted from being a luxury to an operational necessity. Organizations frequently distribute workloads across diverse infrastructure providers like Hetzner—known for its cost-effective, high-performance bare metal servers—and Vultr, celebrated for its global cloud footprint and flexible high-performance cloud compute. However, linking these disparate environments introduces a critical challenge: securing the Data Center Interconnect (DCI) link.

Traditionally, network engineers rely on Layer 3 security mechanisms such as IPsec VPNs or TLS to protect data in transit. While effective, these protocols introduce significant computational overhead, packet encapsulation penalties, and increased latency. For high-throughput, low-latency workloads like database replication, real-time financial transactions, and distributed file systems, Layer 3 encryption can become a massive bottleneck. This is where MACsec (Media Access Control Security), defined under the IEEE 802.1AE standard, provides a transformative alternative by delivering line-rate, hardware-accelerated encryption at Layer 2.

Understanding MACsec (IEEE 802.1AE)

MACsec operates at the Data Link Layer (Layer 2) of the OSI model. Unlike IPsec, which encrypts packets at the Network Layer (Layer 3), MACsec secures all traffic moving over a specific physical or virtual Ethernet link. It guarantees three core security pillars:

Data Confidentiality: Prevents unauthorized eavesdropping by encrypting the ethernet payload.
Data Integrity: Utilizes a cryptographic cipher suite to ensure packets are not altered in transit.
Replay Protection: Assigns sequential packet numbers to prevent man-in-the-middle attackers from intercepting and re-transmitting valid frames.

Because MACsec appends a short 16-byte Security Tag (SecTAG) and a 16-byte Integrity Check Value (ICV) directly to the standard Ethernet frame, it operates with virtually zero performance penalty when backed by hardware acceleration. The entire packet, excluding the Source and Destination MAC addresses, is encrypted, leaving no metadata available for malicious actors analyzing network traffic patterns.

Why Layer 2 Encryption Over Layer 3 VPNs?

When connecting workloads between Hetzner and Vultr, choosing MACsec over IPsec yields substantial technical advantages:

Line-Rate Performance: MACsec is traditionally offloaded to the Network Interface Card (NIC) or switch ASIC. This allows for multi-gigabit encryption without consuming host CPU cycles.
Minimal Overhead: IPsec introduces heavy IP/ESP encapsulation overhead, often reducing the effective Maximum Transmission Unit (MTU) and causing packet fragmentation. MACsec’s fixed 32-byte overhead maximizes throughput efficiency.
Protocol Agnosticism: Since encryption happens at Layer 2, any protocol riding on top of Ethernet (IPv4, IPv6, ARP, PPPoE, or VLAN tags via QinQ) is inherently encrypted without requiring complex routing configurations.

Architectural Blueprint: Bridging Hetzner and Vultr at Layer 2

To implement MACsec between Hetzner and Vultr, we must establish a Layer 2 transport medium between the two providers. Since they do not share a physical local area network, we utilize a dedicated transport layer—such as a carrier-neutral leased line, a software-defined cloud router (e.g., Megaport or PacketFabric), or an overlay Layer 2 tunnel (like VXLAN or GRE over a public backbone)—to present a transparent Ethernet bridge between the two environments.

Design Note: For true hardware-accelerated line-rate MACsec, dedicated bare-metal servers at Hetzner and bare-metal options at Vultr equipped with MACsec-capable NICs (such as Intel E810 or Mellanox ConnectX-6 Dx) are highly recommended. If virtual instances are used, MACsec can still be deployed via software implementations (such as Linux macsec kernel modules), though CPU utilization will scale with traffic volume.

Step-by-Step Implementation Guide on Linux

Below is a technical guide to configuring MACsec manually between a Hetzner host and a Vultr host running modern Linux distributions, assuming a transparent Layer 2 interface (named eth1) has been established between them.

Step 1: Prerequisites and Key Generation

First, ensure the MACsec kernel module is loaded on both nodes:

sudo modprobe macsec

MACsec requires a shared Connectivity Association Key (CAK) and a Connectivity Association Key Name (CKN). Generate two secure, random hexadecimal strings. The CKN is typically a 32-character (16-byte) hex string, and the CAK is a 32-character or 64-character hex string depending on whether you are using AES-128 or AES-256 encryption.

For this architecture, we will use AES-256 for maximum enterprise-grade security:

CKN: 0123456789abcdef0123456789abcdef
CAK: 87654321fedcba987654321fedcba98787654321fedcba987654321fedcba987

Step 2: Configuration on the Hetzner Host

Execute the following commands to initialize the MACsec interface on the Hetzner side. Replace the MAC address with the actual MAC address of the Vultr peer interface.

# Create the macsec0 virtual interface linked to physical interface eth1
sudo ip link add link eth1 name macsec0 type macsec

# Configure the security channel and associate the keys
sudo ip macsec add macsec0 tx sa 0 ckn 0123456789abcdef0123456789abcdef cak 87654321fedcba987654321fedcba98787654321fedcba987654321fedcba987
sudo ip macsec add macsec0 rx address  port 1 sa 0 ckn 0123456789abcdef0123456789abcdef cak 87654321fedcba987654321fedcba98787654321fedcba987654321fedcba987

# Bring the interface up and assign an IP address for the secure interconnect network
sudo ip link set macsec0 up
sudo ip addr add 10.0.100.1/30 dev macsec0

Step 3: Configuration on the Vultr Host

Mirror the configuration on the Vultr host, referencing the Hetzner host's physical MAC address:

# Create the macsec0 virtual interface
sudo ip link add link eth1 name macsec0 type macsec

# Configure the security channel matching the identical CKN and CAK strings
sudo ip macsec add macsec0 tx sa 0 ckn 0123456789abcdef0123456789abcdef cak 87654321fedcba987654321fedcba98787654321fedcba987654321fedcba987
sudo ip macsec add macsec0 rx address  port 1 sa 0 ckn 0123456789abcdef0123456789abcdef cak 87654321fedcba987654321fedcba98787654321fedcba987654321fedcba987

# Bring the interface up and assign the corresponding IP address
sudo ip link set macsec0 up
sudo ip addr add 10.0.100.2/30 dev macsec0

Step 4: Verification

Test connectivity through the newly encrypted tunnel by performing a standard ping from the Hetzner host:

ping 10.0.100.2

To inspect the status, cryptographic statistics, and validation state of the link, use the iproute2 inspection command:

ip macsec show macsec0

This output will confirm whether traffic is successfully passing through encrypted channels and display any integrity errors or packet drop statistics, giving operations teams immediate visibility into the health of the line.

Production Considerations: Automation and Key Management

While manual configuration via ip link works flawlessly for proof-of-concept setups, enterprise production environments demand automated key rotation. Hardcoding static keys exposes infrastructure to long-term cryptographic risks.

To robustly scale MACsec across a dynamic Hetzner-to-Vultr pipeline, network administrators should deploy wpa_supplicant or wpa_cli configured to run the MKA (MACsec Key Agreement) protocol. MKA automates session key generation, handles seamless key rotation without packet loss, and manages peer discovery dynamically across the Layer 2 domain.

Conclusion

Implementing Layer 2 line-rate encryption via MACsec allows enterprises to confidently merge the powerful pricing model of Hetzner with the agile cloud capabilities of Vultr. By securing the Data Center Interconnect at the data link layer, you eliminate the computational bottlenecks of traditional Layer 3 VPNs while achieving comprehensive confidentiality, absolute data integrity, and strict replay protection. As multi-cloud data sovereignty laws become stricter, embedding hardware-accelerated encryption at the root of your inter-datacenter network path is a future-proof strategy for scalable enterprise infrastructure.