StrongSwan with several rightsubnet's - ikev1

[mlimalotic]

ISSUE TYPE

• Bug Report

COMPONENT NAME

VR
StrongSwan

CLOUDSTACK VERSION

ACS 4.11.2.0

CONFIGURATION

Advanced Network
VPC

OS / ENVIRONMENT

SUMMARY

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.

rightsubnet=192.168.198.0/23,192.168.208.0/23,192.168.170.0/23,192.168.234.0/23,192.168.69.0/24

I changed the configuration manually by creating different Child SAs, one for each network, now all networks work.
https://lists.strongswan.org/pipermail/users/2015-November/008966.html

Example:
#conn for vpn-4.3.2.1
conn vpn-4.3.2.1
left=1.2.3.4
leftsubnet=192.168.101.0/24
right=4.3.2.1
type=tunnel
authby=secret
keyexchange=ike
ike=aes128-sha1-modp1024
ikelifetime=1h
esp=aes128-sha1-modp1024
lifetime=8h
keyingtries=2
auto=start
forceencaps=no
dpddelay=30
dpdtimeout=120
dpdaction=restart

conn net-192.168.198.0
also=vpn-4.3.2.1
rightsubnet=192.168.198.0/23
auto=start

conn net-192.168.208.0
also=vpn-4.3.2.1
rightsubnet=192.168.208.0/23
auto=start

conn net-192.168.170.0
also=vpn-4.3.2.1
rightsubnet=192.168.170.0/23
auto=start

conn net-192.168.234.0
also=vpn-4.3.2.1
rightsubnet=192.168.234.0/23
auto=start

conn net-192.168.69.0
also=vpn-4.3.2.1
rightsubnet=192.168.69.0/24
auto=start

[ustcweizhou]

thanks for sharing!

[pdion891]

We will have a look at this, this is for a single site-to-site VPN withc multiple remote subnets?

[JnSchl]

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]

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]

Maybe these links/info can help fixing or identifying this problem:

• [strongSwan] multiple traffic selectors per child_sa
• Cisco Bug: CSCue42170 - IKEv2: Support Multi Selector under the same child SA
• CSCue42170 - IKEv2 Support Multi Selector under the same child SA

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]

Any progress around this one ?

[DagSonsteboSB]

https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Multiple-subnets-per-SA

[onitake]

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]

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 ?