Skip to content

StrongSwan with several rightsubnet's - ikev1 #3138

Closed

Description

@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

Activity

  1. ustcweizhou commented on Jan 19, 2019

    @ustcweizhou
    Contributor

    thanks for sharing!

  2. pdion891 commented on Jan 21, 2019

    @pdion891
    Contributor

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

  3. JnSchl commented on Feb 13, 2019

    @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.

  4. JnSchl commented on Feb 26, 2019

    @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.

  5. JnSchl commented on Feb 26, 2019

    @JnSchl

    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).

  6. andrijapanicsb commented on Mar 20, 2019

    @andrijapanicsb
    Contributor

    Any progress around this one ?

  7. onitake commented on Mar 25, 2019

    @onitake
    Contributor

    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.

  8. andrijapanicsb commented on Apr 3, 2019

    @andrijapanicsb
    Contributor

    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 ?

  9. 23 remaining items

  10. ibragullam commented on Jul 5, 2020

    @ibragullam

    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
    github

  11. andrijapanicsb commented on Aug 11, 2020

    @andrijapanicsb
    Contributor

    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

  12. yadvr commented on Aug 12, 2020

    @yadvr
    Member

    @mlimalotic @andrijapanicsb @onitake @Slair1 can this be closed? The 4.15 systemvmtemplate will ship latest strongswan.

  13. andrijapanicsb commented on Aug 12, 2020

    @andrijapanicsb
    Contributor

    @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

  14. added this to the 4.16.0.0 milestone on Jan 4, 2021
  15. added a commit that references this issue on May 5, 2021
    bc80815
  16. modified the milestones: 4.16.0.0, 4.15.1.0 on May 5, 2021
  17. yadvr commented on May 5, 2021

    @yadvr
    Member

    Improved and fixed by #4953

  18. added a commit that references this issue on May 7, 2021
    f759e07
  19. added a commit that references this issue on Jul 8, 2021
    f1f20af
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions