IPSEC ENDPOINT NAME BUG
The free latest version has a bug. It adds characters to the Endpoint name.
Aug 18 20:27:51.644374: initiating all conns with alias='cftconn_1_knoxxidr_1'
Aug 18 20:27:51.644406: no connection named "cftconn_1_knoxxidr_1"
Aug 18 20:28:01.762342: initiating all conns with alias='cftconn_1_knoxxidr_1'
Aug 18 20:28:01.763290: no connection named "cftconn_1_knoxxidr_1"
Aug 18 20:28:18.459324: forgetting secrets
Aug 18 20:28:18.459388: loading secrets from "/etc/ipsec.secrets"
Aug 18 20:28:19.546430: forgetting secrets
Aug 18 20:28:19.546475: loading secrets from "/etc/ipsec.secrets"
Aug 18 20:28:19.595238: packet from xx.xxx.xxx.:500: initial Main Mode message received but no connection has been authorized with authby=PSK and xauth=no
Aug 18 20:29:35.184073:
Pat Kerpan from Cohesive Networks here. First of all, thank you so much for trying VNS3, we pride ourselves on providing better pricing, better support and better visibility. I am sorry that you were not able to reach out to us on our forums at support.cohesive.net or via email at support@cohesive.net when you had a problem with your IPsec connection. It is true that in VNS3's internal implementation the configuration name of a given Phase2 security association for an IPsec Endpoint is a variant of the Endpoint name you defined. For example if your endpoint is named "My_Super_Duper_endpoint" - the configuration file for its phase2 security associations, which appears in the logs (as you show), is "cftconn_my_super_duper_endpoint_1 (for the first phase2 SA). We prefix with "cftconn_" and suffix with the SA's internal sequential database id (_1). This is an implementation artifact which does not affect display, API, nor most importantly, IPsec negotiation. In fact connection name or endpoint name does NOT have a role in IPsec negotiation. It DOES however show up in the logs, and shows up with the prefix and suffix which you note in the logs. We regret if our approach caused confusion scanning the logs. All that said, the log snippet you pasted indicates a configuration mismatch as VNS3 was attempting to communicate and synchronize with the peer device. It does not indicate any bug. Please consider giving our latest 5.2.x release or 6.0 beta a try and give us a chance to help you solve your connectivity and security needs, and reach out for help if needed.