[Feature Request] IPsec as an SDN Fabric / Encryption Layer

Summary

With the introduction of the WireGuard factory in SDN, Proxmox VE has made great progress toward built-in network encryption. However, for many production environments — especially those running on modern server hardware — IPsec would be a significantly more suitable option. I'd like to request the addition of an IPsec factory, or alternatively an "Enable IPsec encryption" option within existing fabric types (BGP, OSPF, EVPN, etc.).

Rationale

1. Performance: AES-GCM vs. ChaCha20-Poly1305
WireGuard is locked to ChaCha20-Poly1305. On any CPU with AES-NI support (which has been standard on server-grade hardware since ~2011), AES-GCM is substantially faster. This is not a marginal difference:

OpenSSL 3.0.13 — Intel Core i5-14600KF
Benchmark: 10 seconds per test, 4 threads

Benchmark script: https://pastebin.com/ApD8zDyH
Run with: bash ./bench_aead.sh 10 4

The advantage of AES-GCM is even more pronounced on modern AMD EPYC and Ryzen processors, which have highly optimized AES-NI pipelines. WireGuard's documentation acknowledges that ChaCha20 is intended for devices *without* hardware AES acceleration — which describes almost no modern server CPU.

Additionally, IPsec benefits from NIC-level hardware offload via the Linux kernel's XFRM framework (supported by many modern NICs), further reducing CPU load in high-throughput scenarios. WireGuard currently has no equivalent offload capability.

2. Lower MTU Overhead
If the goal is simply encrypting traffic between nodes (without tunneling), IPsec in transport mode with AES-GCM adds approximately 34–38 bytes of overhead per packet (IPv4). In tunnel mode, it's approximately 54–57 bytes.

WireGuard's overhead is fixed at 60 bytes (IPv4) / 80 bytes (IPv6), regardless of use case.

This difference matters at scale — lower per-packet overhead means better effective throughput and reduced fragmentation risk, particularly relevant for jumbo-frame or storage traffic.

3. Enterprise Authentication: IKEv2 + X.509 Certificates (PKI)
IPsec with IKEv2 supports certificate-based mutual authentication using X.509 certificates issued by an internal or external CA. This is a well-understood, auditable model that integrates naturally with existing PKI infrastructure. It also simplifies node authentication management in large clusters compared to WireGuard's per-peer public key distribution.

Proposed Implementation
One of the following approaches would be welcome:
- A dedicated IPsec SDN factory (analogous to the WireGuard factory), using strongSwan or kernel-native XFRM.
- An "Enable IPsec" checkbox/option within existing fabric configurations (BGP, OSPF, EVPN), automatically provisioning transport-mode encryption between fabric peers.

Conclusion
WireGuard is an excellent choice for client-side VPNs and environments without AES-NI. For Proxmox's primary use case — server-to-server encrypted networking on modern hardware — IPsec with AES-GCM offers meaningful advantages in throughput, overhead efficiency, hardware offload support, and enterprise authentication compatibility.

Thank you for considering this.