Multi-subnet setup with VPN – System VMs unreachable and agent not connecting

[TheKunalSen]

I am testing a multi-network setup in Apache CloudStack and running into issues when hosts are placed on different subnets.

Current Setup:
Management server and NFS server are deployed in a 192.168.1.0/24 subnet
Initially, I had KVM hosts in the same .1 network → everything worked seamlessly
I then tried to add a new host in a different public subnet (192.168.2.0/24 network)
What I Did:

Since there was no L3 switch or routing between the two subnets, I configured a site-to-site VPN using StrongSwan between the .1 and .2 networks.

VPN connectivity is working
I can reach the .2 host from the management and NFS servers

However, I had to manually add routes on all machines:

ip route add <subnet> via <vpn_gateway_ip>
After this, the new host in .2 was successfully added to CloudStack
Problem:

Although the host is added successfully:

System VMs (SSVM/CPVM) are created on the .2 host and appear to be running
But:
Agent state is not Up
System VMs are not reachable
Cannot ping system VMs from management server or host
Cannot ping outside host from system VMs
Even within the .2 network, system VM IPs are not reachable
As a result:
No user VMs are getting deployed
Console access is not working
Observation:
System VMs are getting IPs in the .1 network (same as management server)
However, they are running on a host in .2 network
And those .1 system vms ips are not reachable from anywhere not even from the .1 network
This seems to create a routing / network isolation issue

[prashanthr2]

@TheKunalSen
This setup is a non-standard implementation, I don't think this will work because CloudStack requires all hosts within a single Pod to share a Layer 2 broadcast domain, whereas a VPN only provides Layer 3 routing. The System VMs are failing because they are assigned .1.x addresses while residing on a .2.x host.
Because there is no Layer 2 continuity they cannot resolve ARP requests or egress the local bridge making them unreachabel even within the .2.0/24 network. To resolve this try creating a separate Pod for the .2.0/24 network with its own Management IP range, cloudStack will then ensure that any System VM deployed in that Pod receives a local .2.x address ( this may resolve your issue)

[TheKunalSen]

Yes I haven't tried by creating another pod with that .2 network ip ranges

But is this the ideal way to add a remote host into a management server or is there any other way?