andrijapanicsb commented on issue #3138: StrongSwan with several rightsubnet's - ikev1 URL: https://github.com/apache/cloudstack/issues/3138#issuecomment-479662577 OK, so after thorough testing with remote side being pfsense 2.4.4, with 2 remote/right subnets (local to pfsense), and IKEv1 (ancient) and IKEv2, here are the findings below: - **default CloudStack 4.11.2 configuration works FINE with IKEv2** (when having 2 remote/right subnets) - zero hacks or anything - works perfectly well (when configured properly on both sides...) - virtually all HW/SW devices SHOULD support IKEv2, since it's almost 15 years old now ! - IKEv1 is dead old StrongSwan that comes with 4.11.2 systemVM template, is versioned 5.5 - it's behavior (through CloudStack) is to define "keyexchange=ike" in IPsec configuration file for each IPsec tunnel/connection - which (in this 5.5 version means following): " Since (version) 5.0.0 both protocols are handled by Charon and connections marked with ike will use IKEv2 when initiating, but accept any protocol version when responding. " This ^^^ is quote from https://wiki.strongswan.org/projects/strongswan/wiki/Connsection - and in previous versions of StrongSwan there were different defaults, and unless you were very explicit with IKE version (which CloudStack is NOT, to be able to handle both IKEv1 and IKEv2, for compatibility reasons) - in certain setups on remote side (in my example pfsense) the connections might not work. Example of what I mean: - from above quote, if remote side is INITIATING the IPsec tunnel, then CloudStack (StrongSwan) will accept both IKEv1 and IKEv2 (per the config "keyexchange=ike" and the quote above), whilst if CloudStack is the one initiating connections, it will (per the config "keyexchange=ike" and the quote from above) initiate connection as IKEv2. - As mentioned above, in some of my testing - thing did fail - i.e. pfsense set to IKEv1, but I initiate connection from CloudStack, which by default uses IKEv2 So solution for this multiple-right/remote-subnets is to make sure that on remote side you explicitly set IKEv2 in Phase1 configs, and also double-check other phase1 and phase2 configs which remains the common mistake even today (different algorithms, different DH group settings, etc - all these must match on both sides). I would appreciate if someone (confident enough in their IPsec guru skills) can test this in their (problematic) production and confirm the behavior/solution. Considering that we transitioned to StrongSwan, which was a needed step, and considering the IKEv2 is 15 years old now, I suggest we "encourage" users to actually use a newer IKEv2 standard (that is here for last 15 years, give or take) - simple as that - no need for workarounds with defining multiple child SAs etc. (which, I admit, have not tested myself). Opinions ?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
