Does Azure provide a verifiable dataplane egress fence-completion guarantee for existing TCP/TLS connections

Onur KILIÇ 0 Reputation points
2026-10-16T22:32:52.25+00:00

We are evaluating a security-sensitive active/standby gateway architecture on Microsoft Azure.

Before activating a replacement gateway, we must establish that an old gateway cannot transmit any additional bytes beyond a defined terminal network boundary after a positive fencing acknowledgement.

Our requirement includes:

Already established TCP/TLS connections and pending encrypted traffic.

Queued packets in the VM networking stack, virtual NIC, Azure SDN, load balancer and downstream buffers.

All relevant IPv4/IPv6 egress paths.

Persistent enforcement after VM restart, reconnect or network partition.

A verifiable completion acknowledgement produced independently of the old gateway.

We understand that Azure NSG flushConnection can trigger flow re-evaluation, while Azure Load Balancer Admin State Down can preserve established TCP connections.

Our question is whether any currently supported Azure Networking/Compute service or API provides the stronger, versioned fence-completion guarantee described above.

If such a mechanism exists, please identify the exact service, API version, supported configuration, dataplane completion semantics, failure behavior and independent verification method.

If Azure does not provide this guarantee, or if it is not formally documented, please confirm that explicitly.

We would appreciate escalation to Azure Networking/Compute engineering for a written, technically sourced answer. We are seeking architecture feasibility clarification, not reporting a live production incident.

Azure Virtual Network
Azure Virtual Network

An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.

0 comments No comments

1 answer

Sort by: Oldest
  1. Salamat Shah 990 Reputation points MVP
    2026-10-18T08:37:00.8333333+00:00

    Dear Onur,

    Yes, but the solution is architectural rather than a built-in Azure guarantee.

    Options:

    • Application-level fencing (recommended): Use a generation/epoch token. When the standby becomes active, it gets a new token, and downstream services reject traffic from the old gateway generation. This provides a strong, verifiable fence.

    Connection draining + shutdown: Stop accepting new connections, drain existing sessions, then disable NIC/LB access and shut down the VM. This reduces risk but does not provide a formal "zero bytes after acknowledgment" guarantee.

    Mutual TLS certificate rotation: Issue a new certificate to the replacement gateway and revoke/stop trusting the old one. Existing connections eventually terminate, but this is not an instant dataplane fence.

    External lease/quorum system: Use a distributed lock (e.g., consensus-based leader election). Only the current lease holder can transmit. This prevents split-brain behavior and is commonly used for active/standby systems.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.