[
https://issues.apache.org/jira/browse/CLOUDSTACK-10041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262814#comment-16262814
]
JnSchl commented on CLOUDSTACK-10041:
-------------------------------------
Hi, we can confirm this too as soon as CS initiates a IPsec connection IKEv1.
A good example are Sophos UTM or MikroTik firewalls. Currently Sophos UTM
firewalls only support IKEv1. MikroTik supports both IKEv1 and IKEv2. Currently
we are not able to get Sophos UTM firewall up and running with CloudStack
4.10.0.0 (active / passive). MikroTik firewalls do also not work if IKEv1 is
used (IKEv2 works with MikroTik).
The problem seems to be that Sophos UTM and MikroTik firewalls try to initiate
the tunnel using IKEv2 first instead of using IKEv1 only. CloudStack now
"thinks" that IKEv2 should be used and as a result the tunnel does not work.
The "funny" thing is that the IPsec implementation of both firewall vendors is
Strongswan too. Maybe this behavior is related to Strongswan or the Strongswan
implementation in CloudStack.
If required we can provide access to some VPCs to help troubleshoot this
behavior and test several firewall vendors.
> Support to use ikev1 for site-to-site VPN connections
> -----------------------------------------------------
>
> Key: CLOUDSTACK-10041
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10041
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Affects Versions: 4.10.0.0
> Reporter: subhash yedugundla
>
> Currently VR initiates connections using ikev2 by default with strongswan. In
> case, the customer gateway does not support ikev2. The connections would
> result in errors. In order to avoid this, this feature introduces a new
> parameter of ikeversion. Based on that the version with which Virtual Router
> initiates the connection would be decided
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
