cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Schlichtenbrede <>
Subject Working Site-to-Site VPN gets disconnected and VPC seems to forgets ACL’s
Date Thu, 21 Jul 2016 11:55:54 GMT
Hi CloudStack Users and Developers,

we’re currently implementing a new CloudStack environment based on
(System VM Template is 4.6) with XenServer 6.5 SP1 and all the latest

So far everything works as expected we only have an issue regarding the
stability of Site-to-Site VPNs within VPCs and we think ACL’s.

I’ll try to describe the problem and behaviour:

A connected and working S2S VPN switches to disconnected after some time
(usually a few hours). In relation to that the VPC seems to “forget” it’s
ACLs. Restarting only the Network Tier (a VM lives within) solves the
issues for a short period of time (1-3 hours). The state of the VPN
switches to connected and the S2S VPN is working again. Also pinging from
the VM to any public address is working again. Strange is, that for example
browsing to a website is working all the time. Isolated networks however
work like a charm.

We tried to solve this issue through several tests. We changing the network
setup and reducing the complexity just to get this behaviour isolated. But
it’s always the same. We also tried several different connections to
different customer gateways (firewalls) and a VPC-VPN to VPC-VPN connection
to another CloudStack deployment (based on Version 4.5.2) without any

In addition, we tested several setups like CentOS 6 and CentOS 7, but again
always the same. We updated one installation to the master from yesterday – again no success. We do not have any issues with version
4.5.2 – but this installation is in a different datacentre.

Below you’ll find some logs – the relevant IP for this test connection is:

CloudStack Logs (Google Docs):

IPsec Logs from the Virtual Router:

Thank you in advance for your help!


PS: If possible from your site we can do a remote session to take a look at
the setup.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message