[strongSwan] no IDr configured, fall back on IP address - revisit
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Wed Oct 30 17:05:43 CET 2019
> Or might be some peculiar case when subjects of both CA and server's
> cert subjects are identical then something brakes??
Probably be that, too.
You should stop trying to hit so many corner cases. And if you want actual help, provide what I asked.
Am 30.10.19 um 16:27 schrieb lejeczek:
> On 30/10/2019 15:08, Noel Kuntze wrote:
>> Hello L.,
>>
>> You're probably doing it wrong.
>>
>> Please provide your complete config and output of ipsec listcerts.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 30.10.19 um 16:06 schrieb lejeczek:
>>> On 30/10/2019 13:22, Noel Kuntze wrote:
>>>> Hello L.,
>>>>
>>>> Make sure you have the private key for your certificate registered in ipsec.secrets.
>>>> Your config has a couple of problems:
>>>> 1) rightid="C=Shire, O=NRR, CN=*": Wildcards are not supported. Put the actual SAN or DN in the rightid field.
>>>> 2) No configured leftid on the responder: Set leftid to the value that the remote peer expects. E.g. what you configured in rightid.
>>>> It has to be authenticated by the certificate.
>>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>>> Am 29.10.19 um 19:18 schrieb lejeczek:
>>>>> hi everyone,
>>>>>
>>>>> I've asked a long time ago, was not urgent and I did put it off.
>>>>>
>>>>> I have a relatively simple config, on the server:
>>>>>
>>>>> conn to_NRR
>>>>>
>>>>> ike=aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024!
>>>>>
>>>>>
>>>>> esp=aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
>>>>>
>>>>>
>>>>> dpdaction=clear
>>>>> dpddelay=300s
>>>>> rekey=no
>>>>>
>>>>> left=%any
>>>>> #leftsubnet=0.0.0.0/0
>>>>> leftsubnet=10.5.8.0/24
>>>>> leftcert="NRR-vpn-clusterserver.cert.der"
>>>>>
>>>>> right=%any
>>>>> rightdns=10.5.8.204
>>>>> rightsourceip=10.5.8.220,10.5.8.221
>>>>>
>>>>> conn IPSec-IKEv2
>>>>> keyexchange=ikev2
>>>>> auto=add
>>>>>
>>>>> conn IPSec-IKEv2-EAP
>>>>> also="IPSec-IKEv2"
>>>>> #rightauth=eap-mschapv2
>>>>> #rightauthby2=pubkey
>>>>> rightauth=pubkey
>>>>> #rightauthby2=eap-mschapv2
>>>>> rightsendcert=never
>>>>> eap_identity=%any
>>>>>
>>>>> conn CiscoIPSec
>>>>> keyexchange=ikev1
>>>>> forceencaps=yes
>>>>> authby=xauthrsasig
>>>>> xauth=server
>>>>> auto=add
>>>>>
>>>>> and when roadwarrior connects then server logs shows:
>>>>>
>>>>> ...
>>>>>
>>>>> 2[IKE] received cert request for "C=Shire, O=NRR,
>>>>> CN=private.private.tam.cos"
>>>>> 12[IKE] received 1 cert requests for an unknown ca
>>>>> 12[IKE] received end entity cert "C=Shire, O=NRR,
>>>>> CN=sucker at private.private.tam.cos"
>>>>> 12[CFG] looking for peer configs matching
>>>>> 192.168.2.202[%any]...10.4.4.21[C=Shire, O=NRR,
>>>>> CN=sucker at private.private.tam.cos]
>>>>> 12[CFG] candidate "IPSec-IKEv2", match: 1/1/28 (me/other/ike)
>>>>> 12[CFG] candidate "IPSec-IKEv2-EAP", match: 1/1/28 (me/other/ike)
>>>>> 12[CFG] selected peer config 'IPSec-IKEv2'
>>>>> 12[CFG] using certificate "C=Shire, O=NRR,
>>>>> CN=sucker at private.private.tam.cos"
>>>>> 12[CFG] certificate "C=Shire, O=NRR,
>>>>> CN=sucker at private.private.tam.cos" key: 2048 bit RSA
>>>>> 12[CFG] using trusted ca certificate "C=Shire, O=NRR,
>>>>> CN=private.private.tam.cos"
>>>>> 12[CFG] checking certificate status of "C=Shire, O=NRR,
>>>>> CN=sucker at private.private.tam.cos"
>>>>> 12[CFG] ocsp check skipped, no ocsp found
>>>>> 12[CFG] certificate status is not available
>>>>> 12[CFG] certificate "C=Shire, O=NRR, CN=private.private.tam.cos" key:
>>>>> 2048 bit RSA
>>>>> 12[CFG] reached self-signed root ca with a path length of 0
>>>>> 12[IKE] authentication of 'C=Shire, O=NRR,
>>>>> CN=sucker at private.private.tam.cos' with RSA_EMSA_PKCS1_SHA2_256 successful
>>>>> 12[IKE] processing INTERNAL_IP4_ADDRESS attribute
>>>>> 12[IKE] processing INTERNAL_IP4_DNS attribute
>>>>> 12[IKE] peer supports MOBIKE
>>>>> 12[IKE] got additional MOBIKE peer address: 10.0.16.6
>>>>> 12[IKE] got additional MOBIKE peer address: 10.5.10.49
>>>>> 12[CFG] no IDr configured, fall back on IP address
>>>>> 12[IKE] no private key found for '192.168.2.202'
>>>>> 12[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
>>>>> 12[NET] sending packet: from 192.168.2.202[4500] to 10.4.4.21[4500] (80
>>>>> bytes)
>>>>> 12[MGR] checkin and destroy IKE_SA IPSec-IKEv2[2]
>>>>> 12[IKE] IKE_SA IPSec-IKEv2[2] state change: CONNECTING => DESTROYING
>>>>> 03[NET] sending packet: from 192.168.2.202[4500] to 10.4.4.21[4500]
>>>>> 12[MGR] checkin and destroy of IKE_SA successful
>>>>> 07[MGR] checkout IKEv2 SA with SPIs a1791cef0af46d08_i f11cc222ffacd5bf_r
>>>>> 07[MGR] IKE_SA checkout not successful
>>>>>
>>>>> and the roadwarrior's config is:
>>>>>
>>>>> conn to_NRR
>>>>> leftsourceip=%config # This will take an IP from the ip
>>>>> pool on server
>>>>> leftcert="sucker at openstack.der" # The user cert we copied in
>>>>> leftfirewall=yes
>>>>>
>>>>> right=192.168.2.202 # The location of the host, FQDN or
>>>>> IP
>>>>> rightid="C=Shire, O=NRR, CN=*" # the Altname used by the
>>>>> ipsec host
>>>>> rightsubnet=10.5.8.0/24 # the subnet on the servers side you
>>>>> want to access.
>>>>>
>>>>> auto=add
>>>>> #type=route
>>>>> type=passthrough
>>>>>
>>>>> and roadwarrior says:
>>>>>
>>>>> initiating IKE_SA to_nrr[1] to 192.168.2.202
>>>>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
>>>>> N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>>>>> sending packet: from 10.0.0.5[500] to 192.168.2.202[500] (1064 bytes)
>>>>> received packet: from 192.168.2.202[500] to 10.0.0.5[500] (297 bytes)
>>>>> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
>>>>> CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
>>>>> selected proposal:
>>>>> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_AES128_XCBC/ECP_256
>>>>> local host is behind NAT, sending keep alives
>>>>> received cert request for "C=Shire, O=nrr, CN=private.private.tam.cos"
>>>>> sending cert request for "C=shire, O=strongswan, CN=vpn"
>>>>> sending cert request for "C=Shire, O=nrr, CN=private.private.tam.cos"
>>>>> authentication of 'C=Shire, O=nrr, CN=sucker at private.private.tam.cos'
>>>>> (myself) with RSA_EMSA_PKCS1_SHA2_256 successful
>>>>> sending end entity cert "C=Shire, O=nrr, CN=sucker at private.private.tam.cos"
>>>>> establishing CHILD_SA to_nrr{1}
>>>>> generating IKE_AUTH request 1 [ IDi CERT CERTREQ AUTH CPRQ(ADDR DNS) SA
>>>>> TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH)
>>>>> N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
>>>>> splitting IKE message (1664 bytes) into 2 fragments
>>>>> generating IKE_AUTH request 1 [ EF(1/2) ]
>>>>> generating IKE_AUTH request 1 [ EF(2/2) ]
>>>>> sending packet: from 10.0.0.5[4500] to 192.168.2.202[4500] (1236 bytes)
>>>>> sending packet: from 10.0.0.5[4500] to 192.168.2.202[4500] (500 bytes)
>>>>> received packet: from 192.168.2.202[4500] to 10.0.0.5[4500] (80 bytes)
>>>>> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
>>>>> received AUTHENTICATION_FAILED notify error
>>>>> establishing connection 'to_nrr' failed
>>>>>
>>>>>
>>>>> That - 12[IKE] no private key found for '192.168.2.202' - it's the IP of
>>>>> the server thus I presume something there?
>>>>>
>>>>> Certificates seem to load on both ends okey. Both ends are Centos 7 with
>>>>> U5.7.2/K3.10.0-514.26.2.el7.x86_64
>>>>>
>>>>> Could this be some kind of a bug or I've gone blind(from tiredness) ?
>>>>>
>>>>> many thanks, L.
>>>>>
>>>>>
>>> but should identity not be derived/deduced from certificates if those
>>> are all loaded?
>>>
>>> I see the keys on the server are:
>>>
>>> ..
>>>
>>> 00[CFG] loaded RSA private key from
>>> '/etc/strongswan/ipsec.d/private/nrr-vpn-clusterserver.key.der'
>>> 00[CFG] loaded RSA private key from
>>> '/etc/strongswan/ipsec.d/private/sucker at openstack.key.der'
>>> 00[CFG] opening triplet file /etc/strongswan/ipsec.d/triplets.dat
>>> failed: No such file or directory
>>>
>>> now I have rightid on roadwarrior which corresponds to leftid on the
>>> responder/server, which ids are:
>>>
>>> a) tried subject of the cert of server/responder
>>>
>>> b) tried altNames of that cert
>>>
>>> And while "no IDr configured" is gone from logs is still get:
>>>
>>> ...
>>>
>>> 15[CFG] candidate "IPSec-IKEv2", match: 1/1/28 (me/other/ike)
>>> 15[CFG] candidate "IPSec-IKEv2-EAP", match: 1/1/28 (me/other/ike)
>>> 15[CFG] selected peer config 'IPSec-IKEv2'
>>> 15[CFG] using certificate "C=Shire, O=nrr, CN=sucker at private.tam.cos"
>>> 15[CFG] certificate "C=Shire, O=nrr, CN=sucker at private.tam.cos" key:
>>> 2048 bit RSA
>>> 15[CFG] using trusted ca certificate "C=Shire, O=nrr, CN=private.tam.cos"
>>> 15[CFG] checking certificate status of "C=Shire, O=nrr,
>>> CN=sucker at private.tam.cos"
>>> 15[CFG] ocsp check skipped, no ocsp found
>>> 15[CFG] certificate status is not available
>>> 15[CFG] certificate "C=Shire, O=nrr, CN=private.tam.cos" key: 2048 bit
>>> RSA
>>> 15[CFG] reached self-signed root ca with a path length of 0
>>> 15[IKE] authentication of 'C=Shire, O=nrr, CN=sucker at private.tam.cos'
>>> with RSA_EMSA_PKCS1_SHA2_256 successful
>>> 15[IKE] processing INTERNAL_IP4_ADDRESS attribute
>>> 15[IKE] processing INTERNAL_IP4_DNS attribute
>>> 15[IKE] peer supports MOBIKE
>>> 15[IKE] got additional MOBIKE peer address: 10.0.16.6
>>> 15[IKE] got additional MOBIKE peer address: 10.5.10.49
>>> 15[IKE] no private key found for 'private.tam.cos, 10.5.154.204'
>>> 15[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
>>> 15[NET] sending packet: from 10.5.154.202[4500] to 10.5.46.21[4500] (80
>>> bytes)
>>> 15[MGR] checkin and destroy IKE_SA IPSec-IKEv2[1]
>>> 15[IKE] IKE_SA IPSec-IKEv2[1] state change: CONNECTING => DESTROYING
>>>
>>>
>>> many thanks, L
>>>
> Oughh, got it, and... I either got my keys mixed or... server needs CA's
> key???
>
> Or might be some peculiar case when subjects of both CA and server's
> cert subjects are identical then something brakes??
>
> But still connection fails to establish, though it might be something
> else. On roadwarrior:
>
> ...
>
> 06[MGR] checkin of IKE_SA successful
> 04[NET] sending packet: from 10.0.0.5[4500] to 10.5.154.202[4500]
> 04[NET] sending packet: from 10.0.0.5[4500] to 10.5.154.202[4500]
> 03[NET] received packet: from 10.5.154.202[4500] to 10.0.0.5[4500]
> 03[NET] waiting for data on sockets
> 08[MGR] checkout IKEv2 SA by message with SPIs aac5dbe33ca0241f_i
> f1e1d0956f4da4b5_r
> 08[MGR] IKE_SA TO-NRR[4] successfully checked out
> 08[NET] received packet: from 10.5.154.202[4500] to 10.0.0.5[4500] (576
> bytes)
> 08[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP)
> N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR)
> N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(INT_ADDR_FAIL) N(TS_UNACCEPT) ]
> 08[CFG] using trusted certificate "C=Shire, O=NRR,
> CN=private.NRR.tam.cos"
> 08[IKE] rejecting certificate without digitalSignature or nonRepudiation
> keyUsage flags
> 08[IKE] signature validation failed, looking for another key
> 08[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
> 08[NET] sending packet: from 10.0.0.5[4500] to 10.5.154.202[4500] (80
> bytes)
> 08[KNL] deleting SAD entry with SPI cfa253fc
> 08[KNL] deleted SAD entry with SPI cfa253fc
> 08[MGR] checkin and destroy IKE_SA TO-NRR[4]
> 08[IKE] IKE_SA TO-NRR[4] state change: CONNECTING => DESTROYING
>
>
> many thanks, L.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191030/07ff9804/attachment-0001.sig>
More information about the Users
mailing list