Support site-to-site VPN customer gateway with dynamic peer IP (authentication by ID)

[philtreF]

The required feature described as a wish

Support site-to-site VPN customer gateway with dynamic peer IP (authentication by ID)

ISSUE TYPE

• Enhancement Request

COMPONENT NAME

Component:api
Component:UI
Component:systemvm (Virtual Router / strongSwan)

CLOUDSTACK VERSION

4.22.0.0

SUMMARY

Today a VPN Customer Gateway requires a fixed, resolvable peer IP/FQDN in the
Gateway field. This makes it impossible to terminate a site-to-site IPsec
tunnel against a remote endpoint that has a dynamic public IP (a very common
case: branch offices / remote sites behind a consumer or SME ISP link with no
static IP), where the remote peer must instead be identified by an IKE
identity (ID) rather than by its source IP.

The underlying engine (strongSwan on the VR) fully supports this scenario via
right=%any + rightid=<peer-id>. The limitation is purely in the CloudStack
orchestration layer, which models and identifies the peer by IP only.

It would be valuable to allow a Customer Gateway to be created without a fixed
peer IP, identifying the remote peer by an ID instead, so the VR acts as a pure
responder for a dynamic-IP peer.

CURRENT BEHAVIOUR

When the remote site has no static IP, there is no supported way to configure
the tunnel:

• The Gateway field validates the input as an IP/FQDN and rejects anything
  that is not a single resolvable address. For example, entering 0.0.0.0/0
  returns:

  The customer gateway ip/Domain 0.0.0.0/0 is invalid!
  

• If a Customer Gateway ends up with a null/0.0.0.0 peer, the VR
  (CsSite2SiteVpn in systemvm/debian/opt/cloud/bin/configure.py) generates a
  broken configuration:

  • the strongSwan connection is written with right=0.0.0.0 and auto=route,
    which makes charon try to initiate/route toward a null address
    (installing trap failed, remote address unknown in charon log);
  • the INPUT firewall rule for IKE/ESP is generated with -s 0.0.0.0
    (the null host, which matches no real packet) instead of -s 0.0.0.0/0
    (any), so the remote peer's IKE packets are silently dropped by the
    INPUT DROP policy before reaching charon.

• There is no field on the Customer Gateway to declare a remote ID. When we manually open the INPUT firewall, the session establishes without identity verification.

Net result: a dynamic-IP, ID-authenticated remote peer cannot be configured
through the UI/API at all.

EXPECTED BEHAVIOUR

Allow a Customer Gateway to represent a dynamic-IP peer:

• Make the peer Gateway IP optional when a remote ID / peer identity is
  provided (new field). The remote ID replaces the IP as the peer's
  authentication identity (IKE ID types: IPv4/IPv6 address, FQDN, RFC822/email,
  or DN).
• On the VR, when the peer is dynamic, CsSite2SiteVpn should generate:
  • right=%any
  • rightid=<remote-id>
  • auto=add (responder only — the VR cannot initiate toward an unknown IP)
  • the PSK indexed by the remote ID in ipsec.*.secrets (not by IP)
  • an INPUT firewall rule opening UDP/500, UDP/4500 and ESP (proto 50) toward
    the source-NAT IP, either with -s 0.0.0.0/0 or restricted to an
    operator-supplied source range (possibly a list)
• Reuse the existing Passive mode semantics (the VR already supports waiting
  for the remote side to initiate, used today for VPC-to-VPC), since a dynamic
  peer is inherently the initiator.

This has been validated manually on a 4.22 VR (strongSwan 5.9.8): with
right=%any / rightid=<id> / PSK-by-ID and the INPUT rule opened, an IKEv2
tunnel from a dynamic-IP peer authenticating by ID establishes correctly and
passes traffic both ways (ESTABLISHED + INSTALLED, TUNNEL, bidirectional
bytes_i / bytes_o). The only blocker to native support is the orchestration
layer.

PROPOSED IMPLEMENTATION (for discussion)

• API / DB / UI: add an optional remoteid (peer identity) attribute to
  Create/Update VPN Customer Gateway; make gateway optional when remoteid
  is set; expose a clear "dynamic peer IP" indication in the UI.
• VR (CsSite2SiteVpn in configure.py): branch on dynamic peer to emit
  right=%any, rightid, auto=add, PSK-by-ID, and the open INPUT rule.
• Tests: extend test/integration/smoke/test_vpc_vpn.py with a
  dynamic-peer / responder case.

SECURITY CONSIDERATIONS

Because a dynamic peer cannot be filtered by source IP, this mode opens
UDP/500 + UDP/4500 + ESP on the public interface. To keep this safe
and explicit:

• the feature should be opt-in (an explicit "dynamic peer" flag on the
  Customer Gateway), never a silent fallback;
• rightid should be mandatory in this mode so the peer is constrained to a
  known identity;
• IKEv2 should be used (no PSK-hash exposure, unlike IKEv1 aggressive mode);
• the UI should warn that the PSK becomes the primary authentication barrier and
  must be long and random;
• optionally allow restricting the INPUT rule to an operator-supplied source
  CIDR (e.g. the remote ISP's known range) instead of 0.0.0.0/0. As operators oftens have multiple CIDR a list of CIDR would be better.

ENVIRONMENT (where observed)

CloudStack 4.22.0.0
System VM template: systemvm-kvm-4.22.0-x86_64
Virtual Router strongSwan: 5.9.8
Tunnel: IKEv2, PSK, remote peer behind NAT with dynamic public IP,
        authenticating by RFC822-style ID