Hi team,
We've identified an issue in CloudStack's site-to-site (S2S) VPN setup
where tunnels fail to establish when the remote peer is behind a NAT. This
scenario is common in hybrid networks or branch office connections where
the VPN endpoint is not directly exposed to the internet.
*Problem Summary*
In the script configure.py (found in /opt/cloud/bin/configure.py inside
cloud-scripts.tgz), the method configure_ipsec() in class CsSite2SiteVpn
hardcodes the rightid parameter to match the peer's public IP:
file.addeq(" right=%s" % rightpeer)
# file.addeq(" rightid=%s" % rightpeer) # Implicit behavior
This works only when the remote device identifies itself using its public
IP. However, if the peer is behind a NAT, it sends a different ID, causing
the connection to fail. StrongSwan refuses the tunnel with an ID mismatch.
Our tested Fix
To support NATed peers, StrongSwan allows using:
rightid=%any
This accepts any identity presented by the peer, while still enforcing
authentication via PSK and IP address.
We propose to *add the following line* in configure_ipsec():
file.addeq(" rightid=%any")
Right after:
file.addeq(" right=%s" % rightpeer)
This change enables interoperability with NATed devices such as Mikrotik,
Fortigate, and other common firewalls or home routers.
------------------------------
Implementation Context
-
Verified on CloudStack 4.11 and 4.19.
-
The workaround is already used internally by repackaging
cloud-scripts.tgz, but it would be ideal to fix it upstream.
-
No security risks are introduced; PSK authentication and IP filtering
still apply.
-
Optional: this could be made configurable via an advanced setting or VPN
offering parameter.
------------------------------
Can I open the PR?
If this solution sounds acceptable, I’d be happy to open a PR with the
patch and reference this discussion. Please let me know if you're okay with
that.
Thanks in advance!
@rohit.ya...@shapeblue.com <rohit.ya...@shapeblue.com>
--
Francisco Arencibia Quesada.
DevOps Engineer
