Eradicating VPN Sprawl: A Modern Approach to Cross-Organisation Data Exchange

For infrastructure architects and software engineers managing B2B integrations, few things induce as much dread as the phrase: "We need to set up an IPsec VPN with our new partner."

When organisations need to share data with external partners—whether it's a government agency sharing citizen records with a contractor, a hospital sending imaging data to a research facility, or a financial institution connecting to a payment gateway—the default networking approach is almost always a site-to-site VPN.

While a single VPN is manageable, establishing a point-to-point tunnel for every new vendor, partner, and cloud service creates VPN sprawl. This results in a brittle network architecture that is a nightmare to maintain, complex to monitor, and terrifying to secure.

Runbeam is a secure interoperability platform that enables organisations to move data and AI models between on-premises and cloud environments across trust boundaries, without exposing internal networks. It is designed for regulated and security-sensitive industries, including healthcare, government, and critical infrastructure.

Instead of managing dozens of fragile network-layer tunnels, modern engineering teams are replacing VPN sprawl with application-layer data meshes. Here is how it works.

The Problem with VPN Sprawl

Traditional site-to-site VPNs are fundamentally misaligned with modern, API-first software engineering.

1. Over-privileged Access: IPsec VPNs connect networks, not applications. Once the tunnel is up, you must rely on complex, easily misconfigured firewall rules to prevent the partner organization from accessing subnets and servers they shouldn't see.
2. IP Overlap and Routing Nightmares: Connecting two external networks almost always guarantees IP address collisions (e.g., both sides using 10.0.x.x). Engineers are forced to implement messy NAT (Network Address Translation) rules just to make routing work.
3. Operational Friction: Setting up a VPN requires coordination between multiple network engineering teams, exchanging pre-shared keys (PSKs), matching IKE phases, and troubleshooting MTU sizes. It takes weeks of back-and-forth for a connection that should take minutes.
4. Lack of Application Visibility: The network layer has no concept of what data is flowing through it. You cannot natively inspect the API payloads, enforce data minimization policies, or rate-limit specific HTTP routes inside the IPsec tunnel.

The Solution: An Application-Layer Data Mesh

To solve these issues, platform architects are shifting the integration boundary from the network layer (Layer 3) to the application layer (Layer 7).

Instead of extending your local network into a partner's data center, you deploy a secure interoperability gateway—like Runbeam—at the edge of both environments. These gateways form a secure data mesh.

Instead of a persistent, monolithic tunnel, gateways communicate using standard, heavily encrypted web protocols (like HTTPS and HTTP/3) over the public internet.

Why a Data Mesh Outperforms a VPN

• Zero-Trust by Default: Because connectivity happens at the API layer, trust is explicit. You are not granting access to a subnet; you are granting access only to a specific API endpoint (e.g., /api/v1/patient-records), governed by JWT authentication and strict RBAC policies.
• No IP Conflicts: Since communication happens over standard web protocols, internal IP space routing is entirely decoupled. You never have to worry about NAT overlaps with partner networks.
• Granular Policy Enforcement: Because the gateway understands HTTP traffic, you can apply middleware policies directly to the data stream. You can rate-limit partner queries, redact sensitive JSON fields on the fly, or block non-compliant requests before they reach your internal systems.
• Instant Provisioning: Adding a new partner to the mesh is a software configuration change, not a network infrastructure project.

Implementation: The Runbeam Data Mesh Workload

Implementing a secure, multi-node mesh is incredibly straightforward. Instead of configuring IPsec policies, you define ingress and egress routes in code.

You can view the exact configuration for this pattern in our Data Mesh workload.

In this architecture, you define exactly what endpoints are exposed to the mesh (Ingress), and what external partner systems your internal applications can reach (Egress).

# Example Runbeam configuration for a Mesh API Endpoint
[pipelines.mesh_api]
description = "API endpoint exposed to the secure mesh network"
networks = ["mesh_external"]
endpoints = ["mesh_api_endpoint"]
middleware = ["mesh_policies"]
backends = ["internal_api_backend"]
 
# Define what external partners can access this specific API
[pipelines.mesh_api.mesh.ingress.partner_ingress]
type = "http3"
mode = "mesh"
endpoint = "mesh_api_endpoint"
urls = [
    "https://api.myorganization.com/v1"
]
description = "Ingress for partner queries"
enabled = true
 
# Enforce strict application-layer policies
[middleware.mesh_policies]
type = "policies"
 
[middleware.mesh_policies.options]
policies = ["mesh_access"]
 
# Egress: Define how internal apps reach the partner's API securely
[pipelines.mesh_api.mesh.egress.partner_egress]
type = "http3"
mode = "mesh"
backend = "partner_api_system"
description = "Egress to partner organization API"
enabled = true

In the example above, the complexity of a VPN is entirely abstracted away. Communication between the nodes is automatically secured via mutual TLS (mTLS) and HTTP/3, while access is strictly limited to the defined application endpoints.

Industry Applications

This architectural shift is critical for any sector where cross-organisation data exchange is heavily regulated:

• Healthcare: Hospital networks frequently need to share medical imaging with external radiology groups. A data mesh allows the hospital to expose specific DICOMweb endpoints to the external group securely, without opening their clinical network via VPN.
• Government: Federal agencies can share intelligence or citizen data with state-level departments using strict, audited API gateways, ensuring that only authorized data is shared and full audit trails are maintained.
• Finance: Banks integrating with third-party payment processors or fintech applications can use a data mesh to ensure that only the transaction API is exposed, mitigating the risk of a third-party breach spreading laterally into the core banking system.

Stop Managing Tunnels. Start Managing APIs.

VPNs were designed to connect branch offices to headquarters; they were never meant to handle complex, multi-party API integrations in regulated environments. By moving to an application-layer data mesh, engineering teams can dramatically reduce network complexity, improve their security posture, and deploy new partner integrations in minutes rather than months.

To see how easy it is to deploy a mesh network between organizations, explore the Data Mesh workload template or request a demo to discuss your specific B2B integration challenges.