You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
StrongSwan with several rightsubnet's - ikev1 #3138
After upgrading ACS from 4.9.3 (openswan) to 4.11.2 (strongswan), all VPNs with multiple networks have stopped working. Only one of the networks declared in the encryption domain passed traffic.
Hi, we encounter the same issues mainly with IKEv2. So far, we did not test changing the configuration manually – we migrated the affected networks to L2 networks with dedicated virtual routers which are managed outside of CloudStack. This is not a solution.
Well unfortunately, it seems that we have more problems with this issue.
As soon as we update the virtual router to 4.11.2.0 multiple subnets stop working (everything worked before). We run XenServer 7.0 with all latest patches. The virtual routers run as HVM - before PV. We upgraded from 4.10.0.0, CS Management Server currently runs on CentOS 7.6.1810.
So far, we did not find a way to get the affected customer gateways / VPNs up and running again. We currently migrated the affected VPCs to dedicated L2 networks like written before.
These links are related to Cisco ASA and IOS models only. We encountered this issue with other firewalls and vendors too (for example: MikroTik, SecurePoint, Barracuda).
So, it looks like this is currently not possible with CloudStack. Too bad. 😞
We experimented a bit and we discovered another possible bug: CloudStack writes StrongSwan config files into /etc/strongswan.d/, but only uses the IP address of the VPN endpoint for the file name. If multiple tunnels are defined for the same IP, only one of them will stick, as the config file gets overwritten. It would be better if CloudStack used a unique identifier instead.
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).
hi there am trying to configure site to site vpn tunnel from my centos 7 cloud server to my Cisco asa device by using Strongswan but am keep getting this output someone help me am stuck here for weeks
it seems that Cisco ASA does not support multiple connections per CHILD_SA, so a comma separated list of right subnets would not work, and a separate CHILD_SA for each connection (right subnet) is needed, as in the begining of the this thread - this PR looks good #4137
@rhtyd in general yes, but there is a PR that additionally enhances and let one choose if they want separate connections per shild SA/ike v1, v2, or just ike - #4137
Activity
ustcweizhou commentedon Jan 19, 2019
thanks for sharing!
pdion891 commentedon Jan 21, 2019
We will have a look at this, this is for a single site-to-site VPN withc multiple remote subnets?
JnSchl commentedon Feb 13, 2019
Hi, we encounter the same issues mainly with IKEv2. So far, we did not test changing the configuration manually – we migrated the affected networks to L2 networks with dedicated virtual routers which are managed outside of CloudStack. This is not a solution.
Please let us know if we can help somehow.
JnSchl commentedon Feb 26, 2019
Well unfortunately, it seems that we have more problems with this issue.
As soon as we update the virtual router to 4.11.2.0 multiple subnets stop working (everything worked before). We run XenServer 7.0 with all latest patches. The virtual routers run as HVM - before PV. We upgraded from 4.10.0.0, CS Management Server currently runs on CentOS 7.6.1810.
So far, we did not find a way to get the affected customer gateways / VPNs up and running again. We currently migrated the affected VPCs to dedicated L2 networks like written before.
JnSchl commentedon Feb 26, 2019
Maybe these links/info can help fixing or identifying this problem:
These links are related to Cisco ASA and IOS models only. We encountered this issue with other firewalls and vendors too (for example: MikroTik, SecurePoint, Barracuda).
andrijapanicsb commentedon Mar 20, 2019
Any progress around this one ?
DagSonsteboSB commentedon Mar 22, 2019
https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Multiple-subnets-per-SA
onitake commentedon Mar 25, 2019
So, it looks like this is currently not possible with CloudStack. Too bad. 😞
We experimented a bit and we discovered another possible bug: CloudStack writes StrongSwan config files into
/etc/strongswan.d/, but only uses the IP address of the VPN endpoint for the file name. If multiple tunnels are defined for the same IP, only one of them will stick, as the config file gets overwritten. It would be better if CloudStack used a unique identifier instead.andrijapanicsb commentedon Apr 3, 2019
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:
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:
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 ?
23 remaining items
ibragullam commentedon Jul 5, 2020
hi there am trying to configure site to site vpn tunnel from my centos 7 cloud server to my Cisco asa device by using Strongswan but am keep getting this output someone help me am stuck here for weeks
root@imart-linux ibragullam]# strongswan statusall

Status of IKE charon daemon (strongSwan 5.7.2, Linux 3.10.0-1127.13.1.el7.x86_64, x86_64):
uptime: 3 hours, since Jul 05 13:02:21 2020
malloc: sbrk 1724416, mmap 0, used 625376, free 1099040
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 19
loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constrain
ts acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc
cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim
eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xa
uth-generic xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
Listening IP addresses:
10.128.0.8
Connections:
imart-to-ASA5500: %any...41.204.128.170 IKEv1, dpddelay=300s
imart-to-ASA5500: local: [34.71.172.92] uses pre-shared key authentication
imart-to-ASA5500: remote: [41.204.128.170] uses pre-shared key authentication
imart-to-ASA5500: child: 10.128.0.8/32 === dynamic TUNNEL, dpdaction=clear
add_ASA5500_sub0: %any...41.204.152.238 IKEv1, dpddelay=300s
add_ASA5500_sub0: local: [34.71.172.92] uses pre-shared key authentication
add_ASA5500_sub0: remote: [41.204.152.238] uses pre-shared key authentication
add_ASA5500_sub0: child: 10.128.0.8/32 === 41.204.152.238/32[0/10501] TUNNEL, dpdaction=clear
add_ASA5500_sub1: %any...41.204.152.232 IKEv1, dpddelay=300s
add_ASA5500_sub1: local: [34.71.172.92] uses pre-shared key authentication
add_ASA5500_sub1: remote: [41.204.152.232] uses pre-shared key authentication
add_ASA5500_sub1: child: 10.128.0.8/32 === 41.204.152.232/32[0/vcom-tunnel] TUNNEL, dpdaction=clear
Security Associations (1 up, 2 connecting):
imart-to-ASA5500[667]: ESTABLISHED 14 seconds ago, 10.128.0.8[34.71.172.92]...41.204.128.170[41.204.128.170]
imart-to-ASA5500[667]: IKEv1 SPIs: 1ac345a770ba5de9_i* 0711bd6acb769aea_r, rekeying disabled
imart-to-ASA5500[667]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
imart-to-ASA5500[667]: Tasks queued: QUICK_MODE ISAKMP_DPD
imart-to-ASA5500[667]: Tasks active: MODE_CONFIG
add_ASA5500_sub1[3]: CONNECTING, 10.128.0.8[%any]...41.204.152.232[%any]
add_ASA5500_sub1[3]: IKEv1 SPIs: e8ee158c44b97ca0_i* 0000000000000000_r
add_ASA5500_sub1[3]: Tasks queued: QUICK_MODE
add_ASA5500_sub1[3]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD
add_ASA5500_sub0[2]: CONNECTING, 10.128.0.8[%any]...41.204.152.238[%any]
add_ASA5500_sub0[2]: IKEv1 SPIs: a95e5608ea7ba613_i* 0000000000000000_r
add_ASA5500_sub0[2]: Tasks queued: QUICK_MODE
add_ASA5500_sub0[2]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD
andrijapanicsb commentedon Aug 11, 2020
it seems that Cisco ASA does not support multiple connections per CHILD_SA, so a comma separated list of right subnets would not work, and a separate CHILD_SA for each connection (right subnet) is needed, as in the begining of the this thread - this PR looks good #4137
yadvr commentedon Aug 12, 2020
@mlimalotic @andrijapanicsb @onitake @Slair1 can this be closed? The 4.15 systemvmtemplate will ship latest strongswan.
andrijapanicsb commentedon Aug 12, 2020
@rhtyd in general yes, but there is a PR that additionally enhances and let one choose if they want separate connections per shild SA/ike v1, v2, or just ike - #4137
server: Adding VPN options for IKE version and IKE split connections (#…
yadvr commentedon May 5, 2021
Improved and fixed by #4953
server: Adding VPN options for IKE version and IKE split connections (a…
Squashed commit of the following: