Same IP in the cloud: how it actually works

TL;DR

"Same IP" in the cloud is not marketing: it is the result of an L2 tunnel with ARP proxy that makes the cloud VM appear as if it were physically on the customer LAN. Technical walkthrough with ARP traces.

The scenario

Customer with LAN 192.168.10.0/24:

• Physical ERP: 192.168.10.50
• File server: 192.168.10.60
• Default gateway: 192.168.10.1

Disaster: physical ERP down. Sefthy activates the cloud VM.

What happens at the packet level

Without L2 tunnel (classic Layer 3)

1. Internal client runs ping 192.168.10.50.
2. ARP request: "who is 192.168.10.50?"
3. No one answers (physical machine is down).
4. Timeout. Error.

The client must be reconfigured to use the new cloud IP (e.g. 10.99.0.50).

With Sefthy L2 tunnel

1. Internal client runs ping 192.168.10.50.
2. ARP request: "who is 192.168.10.50?"
3. The Sefthy Connector on the LAN responds with the cloud VM's MAC.
4. Packets are encapsulated by the Connector, sent through the encrypted tunnel to the Sefthy datacentre.
5. In the datacentre, the packet is de-encapsulated and delivered to the VM.
6. The VM replies, the packet flows back through the tunnel.
7. The client gets a reply as if the VM were "at home".

Fully transparent. Zero reconfiguration.

ARP proxy: the invisible trick

The Connector acts as an "ARP proxy": it replies to ARP requests for IPs that have been recovered to the cloud, standing in for the down physical machine.

No firewall, DNS or network policy changes on the customer side. From the outside it looks like the physical machine came back online.

Fail-back handling

When the primary returns online, reverse the procedure:

1. Sefthy suspends ARP proxy for that IP.
2. The physical machine responds to ARPs again.
3. Clients reconnect to the primary.
4. The cloud VM is shut down or put in standby.

Orchestrated by the Sefthy Console.

Encryption detail

The ethernet frames encapsulated in the tunnel are encrypted with TLS 1.3 and mutual auth via X.509 certificates. Even if someone intercepts traffic between Connector and datacentre, they only see ciphertext.

Limitations

• Duplicate IPs: if another machine on the LAN has the same IP as the recovered VM, conflict. Handled at setup.
• Heavy multicast: some heavy multicast protocols (e.g. high-definition IPTV) have overhead.
• Latency: 8-15 ms added, irrelevant for 95% of apps.

FAQ

Does it work with DHCP?

Yes. The cloud VM uses the static IP configured for the origin; no DHCP needed.

Can I "see" tunnel traffic?

Only you, from your Connector. Sefthy does not inspect content.

For the L2 pillar, L2 tunnel for DR. For VPN vs L2, Site-to-site VPN vs L2 tunnel.