Cross-Cloud and Hybrid Blockchain Deployment: Building a Highly Available Consensus Network with Overlay VPN

This article introduces how an Overlay VPN architecture built around Nebula can overcome network isolation between nodes deployed across different organizations and environments, enabling secure, automated, and scalable communication between consensus nodes.

Who is this article for? If you want to understand:

• How blockchain nodes deployed across different environments can efficiently form a consensus network
• How to build an automated, scalable, and secure Overlay network

Outline

1. Motivation and Deployment Challenges — Strategy and Pain Points

2. Design: An Architecture Using Overlay VPN and Static Nodes

3. Implementation: Deploying Nodes with Overlay VPN (Nebula)

4. Deployment Results and Conclusion

1. Motivation and Deployment Challenges — Strategy and Pain Points

As a distributed system designed for multi-party collaboration, deploying blockchain nodes across institutions or enterprises is far more complicated than simply “starting a container.”

Each participant typically operates under different IT and network policies, with infrastructure spanning both cloud and on-premises environments. Coordinating and establishing a shared consensus network across these environments therefore becomes a highly complex challenge.

When institutions begin addressing this problem, they need to think through everything from strategic architecture planning to the practical pain points of deployment, identifying potential issues and preparing for them in advance.

【Strategy】We need a financial institution-grade node deployment architecture that can overcome network constraints while maintaining security, flexibility, and operational manageability

When institutions deploy blockchain nodes, the challenge is not simply whether the nodes can communicate with one another. The real question is whether the network can continue to scale, remain securely controlled, and be operated efficiently over time.

What we need is a network infrastructure capable of supporting the long-term operation of the entire blockchain network:

1. Build a cross-organizational infrastructure for the consensus layer

The goal is to allow nodes operated by different organizations to form a stable consensus network without relying on the public Internet or dedicated private lines, while supporting data synchronization and transaction validation.

2. Avoid dependency on any specific cloud provider

We want the architecture to remain independent of built-in mechanisms provided by individual public cloud platforms. Instead, it should use a neutral solution that can operate across different cloud providers as well as on-premises environments.

3. Meet institutional-grade security and operational requirements

Node deployment is not just about connectivity—it also needs to be controllable.

Institutions need answers to questions such as: Who is allowed to connect? How is access authorized? What happens when a node fails and needs to be replaced?

These considerations must be incorporated into the architecture from the beginning.

4. Support future automation and scalability

The deployment process should be scriptable and standardized so that adding new participants or nodes does not require rebuilding the entire environment.

This also means configurations need to be clearly defined and deployment workflows should be modular.

【Pain Points】What real-world challenges did we encounter?

1. Cloud environments cannot communicate directly with one another

Nodes are deployed across different network segments and platforms, each isolated from the others.

Firewalls, NAT, virtual network isolation, and other networking mechanisms prevent nodes from connecting directly.

2. Traditional VPN architectures are not well suited for mesh-based blockchain nodes

VPN solutions such as OpenVPN and IPsec are typically based on centralized or star-topology architectures, which conflict with the mesh-style connectivity required by blockchain consensus nodes.

3. TLS trust mechanisms are complex to configure and difficult to maintain

Each node needs to exchange TLS certificates and configure certificate authorities (CAs).

This process is cumbersome and difficult to automate, and a single configuration error can prevent the entire blockchain network from operating correctly.

4. There is no unified deployment standard or process

Each node may be operated by a different infrastructure team using different deployment practices.

Without shared scripts or configuration templates, environments can quickly become inconsistent, resulting in inefficient deployments and a higher risk of configuration errors.

5. Node connectivity addresses cannot always be known in advance

Dynamic IP addresses, environments where hostnames cannot be assigned, and VM IP changes after restarts make it difficult to statically configure connection parameters between nodes.

Given these challenges, the next section introduces a practical and effective architecture and technical solution: a scalable and automated Overlay VPN communication layer built around Nebula.

2. Design: An Architecture Using Overlay VPN and Static Nodes

Before moving into deployment, we first made a fundamental architectural decision: make every node behave as though it were part of the same private LAN before addressing consensus, transactions, and synchronization.

The purpose of the Overlay VPN architecture is to allow nodes distributed across different cloud and on-premises environments to communicate as if they were internal nodes on the same private network—without relying on public IP connectivity, DNS, or complex NAT traversal mechanisms.

For this implementation, we chose Nebula, an open-source Overlay VPN system designed for communication across hosts and network segments. It provides a secure, stable, and highly controllable networking environment.

With Nebula, each node is assigned a virtual IP address. All communication takes place within this virtual private network, while node authentication and trust authorization are handled through certificates issued by a self-managed CA.

Additional information: How does Nebula provide security guarantees?

Nebula was originally open-sourced by Slack and is now maintained by Defined Networking.

The core ideas behind this approach are:

• Once a node becomes part of the private virtual network, it can naturally establish connections with other nodes
• Communication becomes controllable, IP addresses become predictable, and deployment becomes simpler
• No VPN gateway or centralized server is required
• When new nodes are added in the future, they can join seamlessly with only a predefined IP list

At its core, this architecture introduces a virtual private network layer that is independent of both cloud providers and physical locations.

Each node receives a clean, fixed virtual IP address, and all consensus, synchronization, administration, and monitoring activities operate on top of this virtual IP layer.

The architecture can be summarized as follows:

• Each physical Besu validator node corresponds to a virtual node within the Nebula network
• Once the initial discovery process is completed
• All communication between nodes is encrypted

Nebula Virtual Private Network

Once the Overlay network is established:

• Consensus nodes only need to be started with the corresponding IP list to form the network
• Node maintenance, restarts, and replacements do not affect the overall network topology
• Firewalls are significantly simplified, as only a single UDP port needs to be opened
• There is no longer a need to repeatedly configure NAT rules, exchange certificates, or manage TLS settings between blockchain nodes

This design allows the network to move beyond limitations such as:

“Which node has a dynamic IP?”

“Which organization’s security policy blocks certain traffic?”

“Which environment cannot open a specific port?”

This approach is therefore not merely a collection of configuration settings. It defines a broader deployment methodology:

First create a controllable and predictable private network environment between nodes. Once that foundation exists, many of the complexities surrounding blockchain deployment and cross-organizational collaboration become significantly easier to solve.

This article includes only the first half of the full technical walkthrough. For detailed implementation steps, please read the complete article on Medium: https://medium.com/bsos-taiwan/besu-nebula-ff2764509d87