L2 tunnels for Disaster Recovery: the complete guide

TL;DR

A Layer 2 tunnel is a connection that extends the customer LAN into the cloud while preserving the broadcast domain, MAC and IP. In Disaster Recovery this means the cloud VM boots with the same IP address as the original physical machine. No DNS to change, no NAT, no VPN to configure. The dividend is huge: RTO drops from hours to minutes and legacy applications keep working without recompilation.

What an L2 tunnel really is

Networks talk in layers. Layer 2 is where ethernet frames live, with MAC addresses, letting devices on the same LAN see each other through ARP. Layer 3 is where IP addresses live and where routers decide how to send packets between networks.

A Layer 2 tunnel does something that looks like magic: it takes ethernet frames from a remote network and transports them — encapsulated and encrypted — over the Internet so that on the other side they arrive as if the devices were plugged into the same physical switch. Classic underlying technology: VXLAN, Geneve, EVPN.

For DR this means the cloud VM sits on the same subnet as the customer LAN. Same /24, same default gateway, same ARP space. ARP resolves, DHCP works, the legacy ERP that pings 192.168.10.5 actually finds that IP — only now "192.168.10.5" is a VM in the Sefthy datacentre, not the physical server in the office.

What changes vs classic Layer-3 DR

A classic site-to-site VPN works at Layer 3. The cloud VM gets a new IP (say 10.99.0.5) and reaches local clients (192.168.10.x) through a NATed VPN.

The problems that emerge in practice:

• DNS reconfiguration: internal A records have to change. High TTLs = slow propagation = panicked support calls during the incident.
• Apps with hard-coded IPs: ERPs, network printers, industrial software. Pre-2010 = almost always IPs hard-coded somewhere.
• Customer firewall: rules built for local IPs must be reworked for cloud IPs.
• Re-authentication: some services (Active Directory chief among them) react badly to an IP jump.

All of this, summed under stress, adds 30-90 minutes to actual RTO. The L2 tunnel removes that.

Anatomy of the Sefthy Connector

The piece that makes the L2 tunnel possible is a small appliance (NanoPi R3S LTS in CNC aluminium case) the customer plugs into their LAN. The Connector:

• establishes an encrypted outbound tunnel to the Sefthy datacentre (standard ports, no inbound rules);
• encapsulates ethernet traffic from the local LAN and transports it to the datacentre;
• in the datacentre traffic is de-encapsulated and reaches the recovered VM;
• handles ARP proxy and MAC learning to prevent loops or chatter on the cloud side.

The Connector is fully transparent to the customer's network: no firewall, router or policy changes needed.

The four use cases where L2 tunnels change everything

1. Failing over ERPs with hard-coded IPs

Pre-2010 Italian software (accounting ERPs, industrial software, access-control systems) almost always has IPs hard-coded in source or config. With an L2 tunnel you do not touch them: the recovered VM uses the same IP.

2. Active Directory and mail servers

Changing a Domain Controller's IP is non-trivial. With an L2 tunnel the recovered DC keeps its IP, inter-site replication does not break, clients authenticate immediately.

3. Printers, NAS, IoT devices

Devices statically configured with a specific default gateway are the textbook case where Layer 3 fails. An L2 tunnel ignores the problem entirely: nothing changes from their point of view.

4. DR drills without operational stress

An L2 failover drill can run without disturbing production: the test VM gets a different IP but stays in the same broadcast domain, so administrators can verify reachability with standard tools.

Sefthy L2 tunnel security

The Sefthy L2 tunnel has three protection layers:

• Encryption: all traffic is encrypted at the Connector (TLS 1.3, mutual auth via X.509 certificates).
• Tenant segregation: each customer has its own isolated logical tunnel; it is not technically possible for one customer's traffic to reach another tenant.
• Audit: each tunnel session produces exportable logs (useful for ISO 27001 and NIS2).

"Intercept the traffic between Connector and datacentre" attacks are blocked by encryption. "Tamper with the physical Connector" attacks require physical access to the device.

Latency and performance

Frequent question: does an L2 tunnel add latency?

Short answer: yes, but little. Real measurements over Italian 2.5 Gbps FTTH:

• Connector → Sefthy datacentre latency (Milan-Bari): 8-14 ms;
• sustained throughput: 800-1500 Mbps symmetric;
• jitter: < 2 ms.

For 95% of line-of-business applications (ERPs, mail, file servers) this is invisible to the user. For VoIP and remote desktop it is worth verifying case by case.

When L2 tunnels are not the right pick

Honestly: L2 tunnels are not universally optimal.

• Pure cloud-native workloads: if the app is already stateless and runs in containers, standard Layer 3 is simpler.
• Sub-millisecond latency required: high-frequency trading, real-time simulation. A cloud L2 is not enough.
• Limited bandwidth between site and cloud: below 50 Mbps symmetric the tunnel becomes a bottleneck.

For everything else — 90% of Italian SMBs and MSPs — the L2 tunnel is the biggest qualitative jump you can make in a DR project.

FAQ

Does the Connector open inbound ports on the customer firewall?

No. All traffic is outbound from the Connector to the datacentre. No inbound firewall rules to configure.

How many Connectors do I need for multiple sites?

One per site. Tunnels are independent and Sefthy handles any subnet conflicts with dedicated routing policies.

Does it work behind ISP CGNAT?

Yes. The tunnel always starts outbound from the Connector, so CGNAT and ISP firewalls are not an issue.

Does the L2 tunnel replace the corporate VPN?

No, but it reduces its DR value. For normal user remote access, the corporate VPN is still useful.

Want to understand how to configure a multi-site L2 tunnel? Read Multi-site L2 tunnels or the Connector hardware deep dive.