Hi Francisco,
I worked on a similar issue some months ago. The difference is that the
left side is behind a NAT so I have to set
file.addeq(" left=%s" % local_ip)
file.addeq(" leftid=%s" % leftpeer)
The solution above is similar to yours.
I think it would be good to support a VPN gateway like <public ip/private
ip> (so no database and API changes are required).
inside the VR, we can parse the rightpeer and remote_ip from the VPN
gateway, and configure ipsec vpn accordingly.
Kind regards,
Wei
On Mon, May 26, 2025 at 11:28 AM Francisco Arencibia Quesada <
arencibia.franci...@gmail.com> wrote:
> 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
>
