Hi Jonas, It seems the connection is going down because the dead period detection.
In router run the command 'ipsec auto —status’ to vpn connection status. When the connection is down initiate traffic from the guest vm to other end of vpn and go to router check the ipsec vpn status (ipsec auto —status). This gives wether the connection is up or not in the VR. It takes router status get interval to update the VPN status. The browsing you mentioned is about browsing the other end of vpn servers ? Thanks, Jayapal > On Jul 21, 2016, at 5:25 PM, Jonas Schlichtenbrede > <jonas.schlichtenbr...@gmail.com> wrote: > > Hi CloudStack Users and Developers, > > we’re currently implementing a new CloudStack environment based on 4.8.0.1 > (System VM Template is 4.6) with XenServer 6.5 SP1 and all the latest > updates. > > 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 > success. > > 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 > 4.9.0.0-snapshot – 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: > *85.88.16.104* > > CloudStack 4.8.0.1 Logs (Google Docs): > > https://drive.google.com/open?id=1gqIjDdG1htps4p1t7m1uHSs7aNHplWp1Np83nH6e7zM > > > IPsec Logs from the Virtual Router: > https://drive.google.com/open?id=1ZWvhFu2P_Wv_lF8TgYMmexeS_KDag1Mp-kmuhl8l7uU > > > Thank you in advance for your help! > > Jonas > > PS: If possible from your site we can do a remote session to take a look at > the setup. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.
