Re: [strongSwan] Strongswan 5.6.2: Segfault if charondebug = cfg > 2
Hi, Try with O2, not O3. Kind regards Noel On 05.06.2018 22:11, Sven Anders wrote: > Hello! > > I'm experiencing a segmentation fault, if I set charondebug = cfg to a value > greater than 2. > I'm using Strongwan 5.6.2 on Linux kernel 4.1.39 on a 32 bit system. > > Strongswan was compiled with: > > ./configure CFLAGS="-g -march=core2 -O3 -fstack-protector" > LDFLAGS="-D_FORTIFY_SOURCE=2 -fPIE -pie -Wl,-z,relro,-z,now" --prefix=/usr > --sysconfdir=/etc --enable-aes --enable-bliss --enable-blowfish --enable-ccm > --enable-chapoly --enable-cmac --enable-ctr --enable-des > --enable-fips-prf --enable-gcm --enable-gcrypt --enable-hmac --enable-md4 > --enable-md5 --enable-mgf1 --enable-newhope --enable-nonce --enable-ntru > --enable-openssl --enable-padlock --enable-random --enable-rc2 > --enable-rdrand --enable-aesni --enable-sha1 --enable-sha2 --enable-sha3 > --enable-xcbc > --enable-dnskey --enable-pem --enable-pgp --enable-pkcs1 --enable-pkcs7 > --enable-pkcs8 --enable-pkcs12 --enable-pubkey --enable-sshkey --enable-x509 > --enable-curl --enable-files --enable-ldap --enable-soup --enable-unbound > --disable-winhttp --disable-mysql --enable-sqlite --enable-addrblock > --enable-acert --disable-af-alg --enable-agent --enable-constraints > --enable-coupling --enable-dnscert --enable-eap-sim --enable-eap-sim-file > --disable-eap-sim-pcsc --enable-eap-aka --enable-eap-aka-3gpp > --enable-eap-aka-3gpp2 --enable-eap-simaka-sql --enable-eap-simaka-pseudonym > --enable-eap-simaka-reauth --enable-eap-identity --enable-eap-md5 > --enable-eap-gtc --enable-eap-mschapv2 --enable-eap-tls --enable-eap-ttls > --enable-eap-peap --enable-eap-tnc --enable-eap-dynamic --enable-eap-radius > --enable-ext-auth --enable-ipseckey --disable-keychain --enable-pkcs11 > --enable-revocation --enable-whitelist --enable-xauth-generic > --enable-xauth-eap --enable-xauth-pam --enable-xauth-noauth > --enable-kernel-netlink > --enable-kernel-pfkey --disable-kernel-iph --enable-kernel-libipsec > --disable-kernel-wfp --enable-socket-default --enable-socket-dynamic > --disable-socket-win --enable-stroke --enable-smp --enable-sql --disable-uci > --enable-vici --disable-android-dns --enable-attr --enable-attr-sql > --enable-bypass-lan --enable-counters --enable-dhcp --disable-osx-attr > --disable-p-cscf --enable-resolve --enable-unity --disable-imc-test > --disable-imv-test --enable-imc-scanner --enable-imv-scanner --enable-imc-os > --enable-imv-os --enable-imc-attestation --enable-imv-attestation > --enable-imc-swid --disable-imv-swid --enable-imc-hcd --enable-imv-hcd > --enable-tnc-ifmap --enable-tnc-imc --enable-tnc-imv --enable-tnc-pdp > --enable-tnccs-11 --enable-tnccs-20 --enable-tnccs-dynamic > --disable-android-log --enable-certexpire --enable-connmark --enable-forecast > --enable-duplicheck --enable-error-notify --enable-farp --enable-ha > --enable-led --enable-load-tester --enable-lookip --enable-radattr > --enable-systime-fix --enable-test-vectors --enable-updown --enable-aikgen > --enable-charon --enable-cmd --disable-conftest --disable-dumm > --disable-fast --enable-libipsec --disable-manager --disable-medcli > --disable-medsrv --disable-nm --disable-pki --disable-scepclient > --disable-scripts > --disable-svc --enable-swanctl --disable-tkm --disable-bfd-backtraces > --disable-dbghelp-backtraces --enable-ikev1 --enable-ikev2 > --enable-integrity-test --enable-load-warning --enable-mediation > --disable-unwind-backtraces --disable-ruby-gems --disable-ruby-gems-install > --disable-python-eggs --disable-python-eggs-install --disable-perl-cpan > --disable-perl-cpan-install --enable-tss-trousers --enable-tss-tss2 > --disable-coverage --disable-leak-detective --disable-lock-profiler > --enable-log-thread-ids > > > with "gcc version 4.5.1" (sorry, cannot use a newer compiler on this > system... :-( ) > > > Can anybody reproduce this? > > > > Starting strongSwan 5.6.2 IPsec [starter]... > 2205[DMN] Starting IKE charon daemon (strongSwan 5.6.2, Linux 4.1.39-core2, > i686) > 2205[LIB] plugin 'test-vectors': loaded successfully > 2205[LIB] plugin 'unbound': loaded successfully > 2205[LIB] plugin 'ldap': loaded successfully > 2205[CFG] PKCS11 module '' lacks library path > 2205[LIB] plugin 'pkcs11': loaded successfully > 2205[LIB] plugin 'aesni': loaded successfully > 2205[LIB] plugin 'aes': loaded successfully > 2205[LIB] plugin 'des': loaded successfully > 2205[LIB] plugin 'blowfish': loaded successfully > 2205[LIB] plugin 'rc2': loaded successfully > 2205[LIB] plugin 'sha2': loaded successfully > 2205[LIB] plugin 'sha3': loaded successfully > 2205[LIB] plugin 'sha1': loaded successfully > 2205[LIB] plugin 'md4': loaded successfully > 2205[LIB] plugin 'md5': loaded successfully > 2205[LIB] plugin 'mgf1': loaded successfully > 2205[LIB] plugin 'rdrand': loaded successfully > 2205[LIB] detected RDRAND support, enabled > 2205[LIB] plugin 'random': loaded successfully > 2205[LIB] plugin 'nonce': loaded successfully >
[strongSwan] Strongswan 5.6.2: Segfault if charondebug = cfg > 2
Hello! I'm experiencing a segmentation fault, if I set charondebug = cfg to a value greater than 2. I'm using Strongwan 5.6.2 on Linux kernel 4.1.39 on a 32 bit system. Strongswan was compiled with: ./configure CFLAGS="-g -march=core2 -O3 -fstack-protector" LDFLAGS="-D_FORTIFY_SOURCE=2 -fPIE -pie -Wl,-z,relro,-z,now" --prefix=/usr --sysconfdir=/etc --enable-aes --enable-bliss --enable-blowfish --enable-ccm --enable-chapoly --enable-cmac --enable-ctr --enable-des --enable-fips-prf --enable-gcm --enable-gcrypt --enable-hmac --enable-md4 --enable-md5 --enable-mgf1 --enable-newhope --enable-nonce --enable-ntru --enable-openssl --enable-padlock --enable-random --enable-rc2 --enable-rdrand --enable-aesni --enable-sha1 --enable-sha2 --enable-sha3 --enable-xcbc --enable-dnskey --enable-pem --enable-pgp --enable-pkcs1 --enable-pkcs7 --enable-pkcs8 --enable-pkcs12 --enable-pubkey --enable-sshkey --enable-x509 --enable-curl --enable-files --enable-ldap --enable-soup --enable-unbound --disable-winhttp --disable-mysql --enable-sqlite --enable-addrblock --enable-acert --disable-af-alg --enable-agent --enable-constraints --enable-coupling --enable-dnscert --enable-eap-sim --enable-eap-sim-file --disable-eap-sim-pcsc --enable-eap-aka --enable-eap-aka-3gpp --enable-eap-aka-3gpp2 --enable-eap-simaka-sql --enable-eap-simaka-pseudonym --enable-eap-simaka-reauth --enable-eap-identity --enable-eap-md5 --enable-eap-gtc --enable-eap-mschapv2 --enable-eap-tls --enable-eap-ttls --enable-eap-peap --enable-eap-tnc --enable-eap-dynamic --enable-eap-radius --enable-ext-auth --enable-ipseckey --disable-keychain --enable-pkcs11 --enable-revocation --enable-whitelist --enable-xauth-generic --enable-xauth-eap --enable-xauth-pam --enable-xauth-noauth --enable-kernel-netlink --enable-kernel-pfkey --disable-kernel-iph --enable-kernel-libipsec --disable-kernel-wfp --enable-socket-default --enable-socket-dynamic --disable-socket-win --enable-stroke --enable-smp --enable-sql --disable-uci --enable-vici --disable-android-dns --enable-attr --enable-attr-sql --enable-bypass-lan --enable-counters --enable-dhcp --disable-osx-attr --disable-p-cscf --enable-resolve --enable-unity --disable-imc-test --disable-imv-test --enable-imc-scanner --enable-imv-scanner --enable-imc-os --enable-imv-os --enable-imc-attestation --enable-imv-attestation --enable-imc-swid --disable-imv-swid --enable-imc-hcd --enable-imv-hcd --enable-tnc-ifmap --enable-tnc-imc --enable-tnc-imv --enable-tnc-pdp --enable-tnccs-11 --enable-tnccs-20 --enable-tnccs-dynamic --disable-android-log --enable-certexpire --enable-connmark --enable-forecast --enable-duplicheck --enable-error-notify --enable-farp --enable-ha --enable-led --enable-load-tester --enable-lookip --enable-radattr --enable-systime-fix --enable-test-vectors --enable-updown --enable-aikgen --enable-charon --enable-cmd --disable-conftest --disable-dumm --disable-fast --enable-libipsec --disable-manager --disable-medcli --disable-medsrv --disable-nm --disable-pki --disable-scepclient --disable-scripts --disable-svc --enable-swanctl --disable-tkm --disable-bfd-backtraces --disable-dbghelp-backtraces --enable-ikev1 --enable-ikev2 --enable-integrity-test --enable-load-warning --enable-mediation --disable-unwind-backtraces --disable-ruby-gems --disable-ruby-gems-install --disable-python-eggs --disable-python-eggs-install --disable-perl-cpan --disable-perl-cpan-install --enable-tss-trousers --enable-tss-tss2 --disable-coverage --disable-leak-detective --disable-lock-profiler --enable-log-thread-ids with "gcc version 4.5.1" (sorry, cannot use a newer compiler on this system... :-( ) Can anybody reproduce this? Starting strongSwan 5.6.2 IPsec [starter]... 2205[DMN] Starting IKE charon daemon (strongSwan 5.6.2, Linux 4.1.39-core2, i686) 2205[LIB] plugin 'test-vectors': loaded successfully 2205[LIB] plugin 'unbound': loaded successfully 2205[LIB] plugin 'ldap': loaded successfully 2205[CFG] PKCS11 module '' lacks library path 2205[LIB] plugin 'pkcs11': loaded successfully 2205[LIB] plugin 'aesni': loaded successfully 2205[LIB] plugin 'aes': loaded successfully 2205[LIB] plugin 'des': loaded successfully 2205[LIB] plugin 'blowfish': loaded successfully 2205[LIB] plugin 'rc2': loaded successfully 2205[LIB] plugin 'sha2': loaded successfully 2205[LIB] plugin 'sha3': loaded successfully 2205[LIB] plugin 'sha1': loaded successfully 2205[LIB] plugin 'md4': loaded successfully 2205[LIB] plugin 'md5': loaded successfully 2205[LIB] plugin 'mgf1': loaded successfully 2205[LIB] plugin 'rdrand': loaded successfully 2205[LIB] detected RDRAND support, enabled 2205[LIB] plugin 'random': loaded successfully 2205[LIB] plugin 'nonce': loaded successfully 2205[LIB] plugin 'x509': loaded successfully 2205[LIB] plugin 'revocation': loaded successfully 2205[LIB] plugin 'constraints': loaded successfully 2205[LIB] plugin 'acert': loaded successfully 2205[LIB] plugin 'pubkey': loaded successfully 2205[LIB] plugin
Re: [strongSwan] Loading certificate fails
Oops, wasn't aware that my pki setup was using the openssl plugin even though I was loading the x509 plugin in front of the openssl plugin. Returning to the actual question whether "organisationName" with OID 2.5.4.10 is an "otherName" type we should support. Since the value type is encoded explicitly we could handle any otherName type we have a known OID for. Regards Andreas On 05.06.2018 14:38, Tobias Brunner wrote: Hi Andreas, L6 - generalNames: L7 - generalName: L8 - otherName: => 80 bytes @ 0xd78923 0: 06 03 55 04 0A A0 49 0C 47 67 65 6D 61 74 69 6B ..U...I.Ggematik 16: 20 47 65 73 65 6C 6C 73 63 68 61 66 74 20 66 C3 Gesellschaft f. 32: BC 72 20 54 65 6C 65 6D 61 74 69 6B 61 6E 77 65 .r Telematikanwe 48: 6E 64 75 6E 67 65 6E 20 64 65 72 20 47 65 73 75 ndungen der Gesu 64: 6E 64 68 65 69 74 73 6B 61 72 74 65 20 6D 62 48 ndheitskarte mbH L9 - type-id: 'O' L9 - value: => 73 bytes @ 0xd7892a 0: 0C 47 67 65 6D 61 74 69 6B 20 47 65 73 65 6C 6C .Ggematik Gesell 16: 73 63 68 61 66 74 20 66 C3 BC 72 20 54 65 6C 65 schaft f..r Tele 32: 6D 61 74 69 6B 61 6E 77 65 6E 64 75 6E 67 65 6E matikanwendungen 48: 20 64 65 72 20 47 65 73 75 6E 64 68 65 69 74 73 der Gesundheits 64: 6B 61 72 74 65 20 6D 62 48 karte mbH which is just being ignored. It actually isn't. pki --print only successfully parses the certificate if the openssl plugin is loaded, otherwise it fails right after the output you posted above. The x509 plugin isn't happy about the unparsed generalName (while parse_otherName() returns TRUE, no id_type or encoding is returned, so parse_generalName() eventually returns NULL, which causes x509_parse_generalNames() to fail). Regards, Tobias -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]== smime.p7s Description: S/MIME Cryptographic Signature
Re: [strongSwan] Loading certificate fails
Hi Andreas, > L6 - generalNames: > L7 - generalName: > L8 - otherName: > => 80 bytes @ 0xd78923 > 0: 06 03 55 04 0A A0 49 0C 47 67 65 6D 61 74 69 6B ..U...I.Ggematik >16: 20 47 65 73 65 6C 6C 73 63 68 61 66 74 20 66 C3 Gesellschaft f. >32: BC 72 20 54 65 6C 65 6D 61 74 69 6B 61 6E 77 65 .r Telematikanwe >48: 6E 64 75 6E 67 65 6E 20 64 65 72 20 47 65 73 75 ndungen der Gesu >64: 6E 64 68 65 69 74 73 6B 61 72 74 65 20 6D 62 48 ndheitskarte mbH > L9 - type-id: >'O' > L9 - value: > => 73 bytes @ 0xd7892a > 0: 0C 47 67 65 6D 61 74 69 6B 20 47 65 73 65 6C 6C .Ggematik Gesell >16: 73 63 68 61 66 74 20 66 C3 BC 72 20 54 65 6C 65 schaft f..r Tele >32: 6D 61 74 69 6B 61 6E 77 65 6E 64 75 6E 67 65 6E matikanwendungen >48: 20 64 65 72 20 47 65 73 75 6E 64 68 65 69 74 73 der Gesundheits >64: 6B 61 72 74 65 20 6D 62 48 karte mbH > > which is just being ignored. It actually isn't. pki --print only successfully parses the certificate if the openssl plugin is loaded, otherwise it fails right after the output you posted above. The x509 plugin isn't happy about the unparsed generalName (while parse_otherName() returns TRUE, no id_type or encoding is returned, so parse_generalName() eventually returns NULL, which causes x509_parse_generalNames() to fail). Regards, Tobias
Re: [strongSwan] Loading certificate fails
Hi Mike, with strongSwan 5.7.0dr, pki --print returns the following information: subject: "C=DE, ST=Berlin, L=Berlin, O=gematik GmbH TEST-ONLY - NOT-VALID, CN=80276883130047021254-20170828, postalCode=10117, STREET=Friedrichstra??e 136" issuer: "C=DE, O=gematik GmbH NOT-VALID, OU=Komponenten-CA der Telematikinfrastruktur, CN=GEM.KOMP-CA27 TEST-ONLY" validity: not before Aug 28 14:23:52 2017, ok not after Aug 27 14:23:51 2022, ok (expires in 1544 days) serial:49 flags: serverAuth clientAuth OCSP URIs: http://ocsp-testref.komp-ca.telematik-test/ocsp authkeyId: 7d:6d:64:43:c5:89:f0:04:a7:62:d9:00:6a:eb:64:cc:5e:ed:77:74 subjkeyId: b8:df:ef:87:8e:a7:1b:13:66:90:2a:9f:81:00:46:96:96:93:70:72 pubkey:RSA 2048 bits keyid: ef:5d:7e:46:2c:56:c9:87:33:70:f4:ba:8f:b1:ad:74:54:00:5e:a1 subjkey: b8:df:ef:87:8e:a7:1b:13:66:90:2a:9f:81:00:46:96:96:93:70:72 There is an otherName defined in the subjectAltName extension of type-id "organisation" L6 - generalNames: L7 - generalName: L8 - otherName: => 80 bytes @ 0xd78923 0: 06 03 55 04 0A A0 49 0C 47 67 65 6D 61 74 69 6B ..U...I.Ggematik 16: 20 47 65 73 65 6C 6C 73 63 68 61 66 74 20 66 C3 Gesellschaft f. 32: BC 72 20 54 65 6C 65 6D 61 74 69 6B 61 6E 77 65 .r Telematikanwe 48: 6E 64 75 6E 67 65 6E 20 64 65 72 20 47 65 73 75 ndungen der Gesu 64: 6E 64 68 65 69 74 73 6B 61 72 74 65 20 6D 62 48 ndheitskarte mbH L9 - type-id: 'O' L9 - value: => 73 bytes @ 0xd7892a 0: 0C 47 67 65 6D 61 74 69 6B 20 47 65 73 65 6C 6C .Ggematik Gesell 16: 73 63 68 61 66 74 20 66 C3 BC 72 20 54 65 6C 65 schaft f..r Tele 32: 6D 61 74 69 6B 61 6E 77 65 6E 64 75 6E 67 65 6E matikanwendungen 48: 20 64 65 72 20 47 65 73 75 6E 64 68 65 69 74 73 der Gesundheits 64: 6B 61 72 74 65 20 6D 62 48 karte mbH which is just being ignored. Best regards Andreas On 05.06.2018 11:49, Ettrich, Mike, NMU-DSJ wrote: Hi! Because the strongswan log doesn’t tell a lot about the reasons I have to call for help solving the problem “building CRED_CERTIFICATE - ANY failed, tried 1 builders”. We do use a symlink to the certificate but it seems to be a structural problem. We have problems to load the certificate (80276883130047021254.cert.pem): -BEGIN CERTIFICATE- MIIFNDCCBBygAwIBAgIBSTANBgkqhkiG9w0BAQsFADCBhDELMAkGA1UEBhMCREUx HzAdBgNVBAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxMjAwBgNVBAsMKUtvbXBv bmVudGVuLUNBIGRlciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSAwHgYDVQQDDBdH RU0uS09NUC1DQTI3IFRFU1QtT05MWTAeFw0xNzA4MjgxMjIzNTJaFw0yMjA4Mjcx MjIzNTFaMIGzMQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmVybGluMQ8wDQYDVQQH DAZCZXJsaW4xKzApBgNVBAoMImdlbWF0aWsgR21iSCBURVNULU9OTFkgLSBOT1Qt VkFMSUQxJjAkBgNVBAMMHTgwMjc2ODgzMTMwMDQ3MDIxMjU0LTIwMTcwODI4MQ4w DAYDVQQRDAUxMDExNzEdMBsGA1UECQwURnJpZWRyaWNoc3RyYcOfZSAxMzYwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCehPry2MyAIkDwS3+DYdTQbCr0 FM1W5OqceoP2jK14yFk9iDFOeE0kVld+U3QZyxhVlRX+D4BcRih9tiHt+Smunlln wglltDWLmt1huPZ38cLPRMYk5enZ+OMpj3YgqIUPNne8dYIYld7s4e5+w5xQ0akM 2houp3JK7uxjRRs40nYVo2QdaC+PkfcdBPHaJR9hk26/fD0UO5sLR2lLdRnCuXqh n1JsjcAbyw2Uwd5Uh3eSuklg+fWGpU/AsbqMSY6+LoI7Oaepiu5FAFumaRtC4owX rbNcf3YLy4l2c62Ay/QE00nB0Pv0ZVKS8OasmuTT3ArJiERljwAsfDd/WI1PAgMB AAGjggF+MIIBejAdBgNVHQ4EFgQUuN/vh46nGxNmkCqfgQBGlpaTcHIwHwYDVR0j BBgwFoAUfW1kQ8WJ8ASnYtkAautkzF7td3QwSwYIKwYBBQUHAQEEPzA9MDsGCCsG AQUFBzABhi9odHRwOi8vb2NzcC10ZXN0cmVmLmtvbXAtY2EudGVsZW1hdGlrLXRl c3Qvb2NzcDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDAQYIKwYBBQUHAwIwIAYDVR0gBBkwFzAKBggqghQATASBIzAJBgcq ghQATARQMFsGA1UdEQRUMFKgUAYDVQQKoEkMR2dlbWF0aWsgR2VzZWxsc2NoYWZ0 IGbDvHIgVGVsZW1hdGlrYW53ZW5kdW5nZW4gZGVyIEdlc3VuZGhlaXRza2FydGUg bWJIMC8GBSskCAMDBCYwJDAiMCAwHjAcMA8MDU5ldHprb25uZWt0b3IwCQYHKoIU AEwEaDANBgkqhkiG9w0BAQsFAAOCAQEAIC2ftr1046BhsVdi92EIefD/23aDDgFA 86ChWepmEfZ+n56QCYsLdw3ugVgUVBmBF6CnwrmKN91tglS3EN0IV2G2UdzitdFB xAcIfRB2rcVAfQu8wcegQSVPYtOk0N8v/QOayLg8gYdEdxpRihYOyHBtbURE3Dyt UFxuqxleE32sVZlYnf0m7SmXt9XtkO7eN+synlJBR8JUogyxQfMOqwfZPK7Rf7em chKs4WFQtcPsPGzU4Q1yRzG3PxAiDVUgdCj2zuNl0epRkjmE7ZPRI/umtyorJmx5 lWA6ti+ZxtUZUImLbtKZy3CeNhohFUNQ5oveQ42ADyyp3SHnGssBQg== -END CERTIFICATE- PKI – Call: ipsec pki --print --in 80276883130047021254.cert.pem building CRED_CERTIFICATE - X509 failed, tried 3 builders parsing input failed OpenSsl – Call: openssl x509 -in 80276883130047021254.cert.pem -text –noout X509v3 Subject Alternative Name: othername: 1.3.36.8.3.3: Netzkonnektor0...*...L.h0.0.. Signature Algorithm: sha256WithRSAEncryption 20:2d:9f:b6:bd:74:e3:a0:61:b1:57:62:f7:61:08:79:f0:ff: db:76:83:0e:01:40:f3:a0:a1:59:ea:66:11:f6:7e:9f:9e:90: 09:8b:0b:77:0d:ee:81:58:14:54:19:81:17:a0:a7:c2:b9:8a: 37:dd:6d:82:54:b7:10:dd:08:57:61:b6:51:dc:e2:b5:d1:41: c4:07:08:7d:10:76:ad:c5:40:7d:0b:bc:c1:c7:a0:41:25:4f: 62:d3:a4:d0:df:2f:fd:03:9a:c8:b8:3c:81:87:44:77:1a:51: 8a:16:0e:c8:70:6d:6d:44:44:dc:3c:ad:50:5c:6e:ab:19:5e:
[strongSwan] Loading certificate fails
Hi! Because the strongswan log doesn't tell a lot about the reasons I have to call for help solving the problem "building CRED_CERTIFICATE - ANY failed, tried 1 builders". We do use a symlink to the certificate but it seems to be a structural problem. We have problems to load the certificate (80276883130047021254.cert.pem): -BEGIN CERTIFICATE- MIIFNDCCBBygAwIBAgIBSTANBgkqhkiG9w0BAQsFADCBhDELMAkGA1UEBhMCREUx HzAdBgNVBAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxMjAwBgNVBAsMKUtvbXBv bmVudGVuLUNBIGRlciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSAwHgYDVQQDDBdH RU0uS09NUC1DQTI3IFRFU1QtT05MWTAeFw0xNzA4MjgxMjIzNTJaFw0yMjA4Mjcx MjIzNTFaMIGzMQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmVybGluMQ8wDQYDVQQH DAZCZXJsaW4xKzApBgNVBAoMImdlbWF0aWsgR21iSCBURVNULU9OTFkgLSBOT1Qt VkFMSUQxJjAkBgNVBAMMHTgwMjc2ODgzMTMwMDQ3MDIxMjU0LTIwMTcwODI4MQ4w DAYDVQQRDAUxMDExNzEdMBsGA1UECQwURnJpZWRyaWNoc3RyYcOfZSAxMzYwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCehPry2MyAIkDwS3+DYdTQbCr0 FM1W5OqceoP2jK14yFk9iDFOeE0kVld+U3QZyxhVlRX+D4BcRih9tiHt+Smunlln wglltDWLmt1huPZ38cLPRMYk5enZ+OMpj3YgqIUPNne8dYIYld7s4e5+w5xQ0akM 2houp3JK7uxjRRs40nYVo2QdaC+PkfcdBPHaJR9hk26/fD0UO5sLR2lLdRnCuXqh n1JsjcAbyw2Uwd5Uh3eSuklg+fWGpU/AsbqMSY6+LoI7Oaepiu5FAFumaRtC4owX rbNcf3YLy4l2c62Ay/QE00nB0Pv0ZVKS8OasmuTT3ArJiERljwAsfDd/WI1PAgMB AAGjggF+MIIBejAdBgNVHQ4EFgQUuN/vh46nGxNmkCqfgQBGlpaTcHIwHwYDVR0j BBgwFoAUfW1kQ8WJ8ASnYtkAautkzF7td3QwSwYIKwYBBQUHAQEEPzA9MDsGCCsG AQUFBzABhi9odHRwOi8vb2NzcC10ZXN0cmVmLmtvbXAtY2EudGVsZW1hdGlrLXRl c3Qvb2NzcDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDAQYIKwYBBQUHAwIwIAYDVR0gBBkwFzAKBggqghQATASBIzAJBgcq ghQATARQMFsGA1UdEQRUMFKgUAYDVQQKoEkMR2dlbWF0aWsgR2VzZWxsc2NoYWZ0 IGbDvHIgVGVsZW1hdGlrYW53ZW5kdW5nZW4gZGVyIEdlc3VuZGhlaXRza2FydGUg bWJIMC8GBSskCAMDBCYwJDAiMCAwHjAcMA8MDU5ldHprb25uZWt0b3IwCQYHKoIU AEwEaDANBgkqhkiG9w0BAQsFAAOCAQEAIC2ftr1046BhsVdi92EIefD/23aDDgFA 86ChWepmEfZ+n56QCYsLdw3ugVgUVBmBF6CnwrmKN91tglS3EN0IV2G2UdzitdFB xAcIfRB2rcVAfQu8wcegQSVPYtOk0N8v/QOayLg8gYdEdxpRihYOyHBtbURE3Dyt UFxuqxleE32sVZlYnf0m7SmXt9XtkO7eN+synlJBR8JUogyxQfMOqwfZPK7Rf7em chKs4WFQtcPsPGzU4Q1yRzG3PxAiDVUgdCj2zuNl0epRkjmE7ZPRI/umtyorJmx5 lWA6ti+ZxtUZUImLbtKZy3CeNhohFUNQ5oveQ42ADyyp3SHnGssBQg== -END CERTIFICATE- PKI - Call: ipsec pki --print --in 80276883130047021254.cert.pem building CRED_CERTIFICATE - X509 failed, tried 3 builders parsing input failed OpenSsl - Call: openssl x509 -in 80276883130047021254.cert.pem -text -noout X509v3 Subject Alternative Name: othername: 1.3.36.8.3.3: Netzkonnektor0...*...L.h0.0.. Signature Algorithm: sha256WithRSAEncryption 20:2d:9f:b6:bd:74:e3:a0:61:b1:57:62:f7:61:08:79:f0:ff: db:76:83:0e:01:40:f3:a0:a1:59:ea:66:11:f6:7e:9f:9e:90: 09:8b:0b:77:0d:ee:81:58:14:54:19:81:17:a0:a7:c2:b9:8a: 37:dd:6d:82:54:b7:10:dd:08:57:61:b6:51:dc:e2:b5:d1:41: c4:07:08:7d:10:76:ad:c5:40:7d:0b:bc:c1:c7:a0:41:25:4f: 62:d3:a4:d0:df:2f:fd:03:9a:c8:b8:3c:81:87:44:77:1a:51: 8a:16:0e:c8:70:6d:6d:44:44:dc:3c:ad:50:5c:6e:ab:19:5e: 13:7d:ac:55:99:58:9d:fd:26:ed:29:97:b7:d5:ed:90:ee:de: 37:eb:32:9e:52:41:47:c2:54:a2:0c:b1:41:f3:0e:ab:07:d9: 3c:ae:d1:7f:b7:a6:72:12:ac:e1:61:50:b5:c3:ec:3c:6c:d4: e1:0d:72:47:31:b7:3f:10:22:0d:55:20:74:28:f6:ce:e3:65: d1:ea:51:92:39:84:ed:93:d1:23:fb:a6:b7:2a:2b:26:6c:79: 95:60:3a:b6:2f:99:c6:d5:19:50:89:8b:6e:d2:99:cb:70:9e: 36:1a:21:15:43:50:e6:8b:de:43:8d:80:0f:2c:a9:dd:21:e7: 1a:cb:01:42 If this certificate is used by our Test-Roadwarrior Charon.log contains: Jun 5 09:20:56 14[LIB] building CRED_CERTIFICATE - ANY failed, tried 1 builders Jun 5 09:20:56 14[CFG] loading certificate from 'my.C_NK_VPN.pem' failed Kind regards, Mike.
Re: [strongSwan] "sending keep alive" seems breaking VPN connection
Hi,
I think that's wrong. The acquires show that the packets are between the IKE
ports, which doesn't seem to work over the tunnel. This shouldn't happen in the
first place. It's a side effect of the mark and PBR rules that are installed:
The VTI uses the mark (0x)2
> /etc/ipsec.script.sh
>
> set -o nounset
> set -o errexit
> VPN_USER="vpn"
> VTI_INTERFACE="vti0"
> case "${PLUTO_VERB}" in
> up-client)
> ip tunnel add "${VTI_INTERFACE}" local "${PLUTO_ME}" remote
> "${PLUTO_PEER}" mode vti \
> okey "${PLUTO_MARK_OUT%%/*}" ikey
> "${PLUTO_MARK_IN%%/*}"
> ip link set "${VTI_INTERFACE}" up
> sysctl -w "net.ipv4.conf.${VTI_INTERFACE}.disable_policy=1"
> sysctl -w "net.ipv4.conf.${VTI_INTERFACE}.rp_filter=2"
> ip addr add ${PLUTO_MY_SOURCEIP} dev "${VTI_INTERFACE}"
> if [[ `ip rule list | grep -c 0x1` == 0 ]]; then
> ip rule add from all fwmark 0x1 lookup $VPN_USER <--- redirects
> the packets
> fi
> # Launch routing script
> /etc/ipsec.route.sh
> ;;
> down-client)
> ip tunnel del "${VTI_INTERFACE}"
> ;;
> esac
>
>
> /etc/ipsec.route.sh
>
> export TABLE_ID="vpn"
> export VPN_USER="vpn"
> export VTI_INTERFACE="vti0"
> export LOCAL_IP="10.211.55.3"
>
> # Flush iptables rules
> iptables -F -t nat
> iptables -F -t mangle
> iptables -F -t filter
> # Mark packets from $VPN_USER
> iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
> iptables -t mangle -A OUTPUT ! --dest $LOCAL_IP -m owner --uid-owner
> $VPN_USER -j MARK --set-mark 0x1
> iptables -t mangle -A OUTPUT ! --src $LOCAL_IP -j MARK --set-mark 0x1 <-
> this is always true here!
> iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
> # Deny $VPN_USER to access other interfaces than lo
> # iptables -A OUTPUT ! -o lo -m owner --uid-owner $VPN_USER -j DROP
> # Allow $VPN_USER to access lo and VPN interfaces
> iptables -A OUTPUT -o lo -m owner --uid-owner $VPN_USER -j ACCEPT
> iptables -A OUTPUT -o $VTI_INTERFACE -m owner --uid-owner $VPN_USER -j
> ACCEPT
>
> # Allow response from $VPN_INTERFACE
> iptables -A INPUT -i $VTI_INTERFACE -m conntrack --ctstate ESTABLISHED -j
> ACCEPT
> # Masquarade packets on $VPN_INTERFACE
> iptables -t nat -A POSTROUTING -o $VTI_INTERFACE -j MASQUERADE
> # Routing rules
> GATEWAY=$(ifconfig $VTI_INTERFACE | <- use ip route with, for example,
> json output.
> egrep -o '([0-9]{1,3}\.){3}[0-9]{1,3}' |
> egrep -v '255|(127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})' | tail
> -n1)
> ip route replace default via $GATEWAY table $TABLE_ID <- Use the
> interface name instead
> ip route append default via 127.0.0.1 dev lo table $TABLE_ID <- this is
> superfluous.
> ip route flush cache <- this is superfluous.
The problem is that "iptables -t mangle -A OUTPUT ! --src $LOCAL_IP -j MARK
--set-mark 0x1" applies to all packets here. Add the owner match here, too and
it should work.
Kind regards
Noel
On 05.06.2018 11:11, Tobias Brunner wrote:
> Hi Gilles,
>
>> Following your comment, it seems the issue comes first for "Hide.me"
>> which is not answering correctly to the "CREATE_CHILD_SA"
>> request.
>
> No, the problem is that an acquire is generated in the first place. The
> behavior by the peer is definitely not correct, but that's not the
> actual problem (and fixing it wouldn't get you anything).
>
>> - Does it mean that if they fix this issue, I will not lose anymore
>> the connection on my side?
>
> No, as I said, you have to fix your routing/iptables setup so the
> correct source IP is used for traffic that's routed via VTI device.
>
>> If it is not possible for them to change the behaviour of their VPN, you
>> mentioned I may handle it on my side by fixing the route when the
>> virtual IP is created. Can you provide more details?
>
> Install routes with `src ${PLUTO_MY_SOURCEIP}` so that source IP is used
> or NAT traffic to the virtual IP before it hits VTI device and the IPsec
> policies.
>
> Regards,
> Tobias
>
signature.asc
Description: OpenPGP digital signature
Re: [strongSwan] "sending keep alive" seems breaking VPN connection
Hi Gilles,
> Following your comment, it seems the issue comes first for "Hide.me"
> which is not answering correctly to the "CREATE_CHILD_SA"
> request.
No, the problem is that an acquire is generated in the first place. The
behavior by the peer is definitely not correct, but that's not the
actual problem (and fixing it wouldn't get you anything).
> - Does it mean that if they fix this issue, I will not lose anymore
> the connection on my side?
No, as I said, you have to fix your routing/iptables setup so the
correct source IP is used for traffic that's routed via VTI device.
> If it is not possible for them to change the behaviour of their VPN, you
> mentioned I may handle it on my side by fixing the route when the
> virtual IP is created. Can you provide more details?
Install routes with `src ${PLUTO_MY_SOURCEIP}` so that source IP is used
or NAT traffic to the virtual IP before it hits VTI device and the IPsec
policies.
Regards,
Tobias
Re: [strongSwan] "sending keep alive" seems breaking VPN connection
Hi Tobias,
Thanks for this analysis.
Following your comment, it seems the issue comes first for "Hide.me" which
is not answering correctly to the "CREATE_CHILD_SA" request. Unfortunately,
I cannot have access to their log but I can raise a ticket to their support.
- Does it mean that if they fix this issue, I will not lose anymore the
connection on my side?
If it is not possible for them to change the behaviour of their VPN, you
mentioned I may handle it on my side by fixing the route when the virtual
IP is created. Can you provide more details?
Will this modification also prevent the communication to be destroyed?
Indeed, if my example, I mentioned only one lost of connection and the
creation of a new one but this issue is an infinite loop (Means each 2-3
minutes, connection is not working anymore).
Regards,
Gilles
On Tue, Jun 5, 2018 at 10:06 AM, Tobias Brunner
wrote:
> Hi Gilles,
>
> > Mon, 2018-06-04 23:04 09[KNL] received a XFRM_MSG_ACQUIRE
> > Mon, 2018-06-04 23:04 09[KNL] XFRMA_TMPL
> > Mon, 2018-06-04 23:04 09[KNL] XFRMA_MARK
> > Mon, 2018-06-04 23:04 09[KNL] creating acquire job for policy
> 192.168.0.30/32[udp/ipsec-nat-t] === 5.79.71.212/32[udp/ipsec-nat-t] with
> reqid {1}
>
> This triggers a CREATE_CHILD_SA exchange, which the other peer never
> answers (check the log there to find out why), eventually causing the
> destruction of the SA:
>
> > Mon, 2018-06-04 23:04 09[ENC] generating CREATE_CHILD_SA request
> 7 [ SA No KE TSi TSr ]> ...
> > Mon, 2018-06-04 23:07 04[IKE] giving up after 5 retransmits
> > ...
> > Mon, 2018-06-04 23:07 04[IKE] IKE_SA VPN[1] state change:
> ESTABLISHED => DESTROYING
>
> Then due to dpdaction=restart the SA is recreated. Actually, two
> CHILD_SAs are created (because of the queued CREATE_CHILD task).
> Strangely, the peer now responds to this additional CREATE_CHILD_SA
> request, but your updown script can't actually handle this duplicate
> CHILD_SA properly.
>
> To avoid the unnecessary and problematic acquire you have to fix the
> routes (or iptables rules) so that the source address is correct once
> the virtual IP is installed (as you can see above the physical IP is
> used for some packets routed via VTI device and that triggers an acquire
> because the IPsec policy is only for the virtual IP).
>
> Regards,
> Tobias
>
Re: [strongSwan] "sending keep alive" seems breaking VPN connection
Hi Gilles,
> Mon, 2018-06-04 23:04 09[KNL] received a XFRM_MSG_ACQUIRE
> Mon, 2018-06-04 23:04 09[KNL] XFRMA_TMPL
> Mon, 2018-06-04 23:04 09[KNL] XFRMA_MARK
> Mon, 2018-06-04 23:04 09[KNL] creating acquire job for policy
> 192.168.0.30/32[udp/ipsec-nat-t] === 5.79.71.212/32[udp/ipsec-nat-t] with
> reqid {1}
This triggers a CREATE_CHILD_SA exchange, which the other peer never
answers (check the log there to find out why), eventually causing the
destruction of the SA:
> Mon, 2018-06-04 23:04 09[ENC] generating CREATE_CHILD_SA request 7 [
> SA No KE TSi TSr ]> ...
> Mon, 2018-06-04 23:07 04[IKE] giving up after 5 retransmits
> ...
> Mon, 2018-06-04 23:07 04[IKE] IKE_SA VPN[1] state change: ESTABLISHED
> => DESTROYING
Then due to dpdaction=restart the SA is recreated. Actually, two
CHILD_SAs are created (because of the queued CREATE_CHILD task).
Strangely, the peer now responds to this additional CREATE_CHILD_SA
request, but your updown script can't actually handle this duplicate
CHILD_SA properly.
To avoid the unnecessary and problematic acquire you have to fix the
routes (or iptables rules) so that the source address is correct once
the virtual IP is installed (as you can see above the physical IP is
used for some packets routed via VTI device and that triggers an acquire
because the IPsec policy is only for the virtual IP).
Regards,
Tobias
