WireGuard as a VPN option on the Virtual Router

Examinez d’abord la PR fermée #9977 ainsi que les diapositives et la vidéo de CCC 2024, puis suivez la question de conception de l’API encore non résolue à travers les composants Virtual Router, Network, API et UI. La tâche est considérée comme terminée lorsqu’un chemin d’implémentation réalisable et le périmètre nécessaire pour ajouter la prise en charge de WireGuard dans une future version ont été établis.

ISSUE TYPE

• Improvement Request / Feature Idea

COMPONENT NAME

Virtual Router, Network, API, UI

CLOUDSTACK VERSION

4.22.1.0

SUMMARY

CloudStack today offers L2TP for remote access and IPsec for site-to-site. We run CloudStack in production and a large share of our customer VPN problems come from the limits of these options. WireGuard would solve most of them:

Single UDP port. One port to allow, in and out, instead of IKE plus ESP and the NAT-T handling that comes with IPsec. It is far simpler to manage on customer-side firewalls, and much easier for us to support.

Works without a fixed public IP. Many of our customers sit behind dynamic addressing or carrier NAT and cannot establish an IPsec tunnel as the current IPsec S2S doesn't support authentication by Id, which has an open issue 13512. WireGuard traverses NAT with a single port and re-establishes on its own when the address changes. This is our single most common VPN complaint.

No negotiation matrix to get wrong. Bringing up an IPsec site-to-site tunnel means both ends agreeing on IKE version, DH group, encryption, hashing, authentication, PFS and lifetimes, in two separate phases. A single mismatch anywhere produces a tunnel that will not come up, often with no useful error on either side, and the customer equipment is usually out of our control. This is where most of our site-to-site setup time goes. WireGuard has no negotiation at all: exchange public keys and the tunnel is up.

Lower CPU cost. In our experience an IPsec tunnel pins encryption to one core and saturates it, capping tunnel throughput well below the link. WireGuard is noticeably lighter for the same traffic due to its modern encryption algorithms.

One protocol for both use cases. Remote access and site-to-site with the same configuration model, instead of two separate stacks.

Home routers already support it. A large number of consumer and SOHO routers now ship WireGuard. That lets a customer connect their whole home or small office to their tenant directly from the router, and route only the tenant prefixes over the tunnel while normal internet traffic stays local. Split routing like this is not workable with the current L2TP client setup, and this is exactly what many of our customers are asking for.

PRIOR ART

This has already been proposed and partly implemented in the project:

• PR #9977 — "Add Wireguard VPN integration" (https://github.com/apache/cloudstack/pull/9977), opened Nov 2024 by @Dav-11, closed by the author in June 2025 without being merged. He stated he could no longer continue and offered to hand over the work to anyone interested.
• CCC 2024 talk "Integrating Wireguard into Cloudstack VR" by Marco Ziglioli (CDLAN), the design behind that PR:
  • Slides: https://www.cloudstackcollab.org/wp-content/uploads/2024/12/CCC-2024-CDLAN-Integrating-Wireguard-into-Cloudstack-VR.pdf
  • Video: https://www.youtube.com/watch?v=SjOD-gXCAk0

The PR did not stall because the feature was rejected. It stalled on an open API design question, then on rebase conflicts, and finally on the author's availability.

Is it feasible to revive this and get WireGuard support into a future release? There is real demand for it among our customers, and the groundwork already exists in the closed PR and the CCC material.