[strongSwan] no IDr configured, fall back on IP address - revisit

lejeczek peljasz at yahoo.co.uk
Wed Oct 30 17:35:30 CET 2019


On 30/10/2019 16:05, Noel Kuntze wrote:
>> 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.
>>
I went back and redone my certs, now CA and server certs have different
SDNs but it seems that strogswan IDs must be those from CA's cert
subject(at least on my system). If I use SDN from server cert then I
still get 'no private key found for' (even though key is loaded)

Does it mean that IDs must be CA's ? (I mean is this how strongswan must
have it, always & only CA's)

many thanks, L.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1757 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191030/700fd12d/attachment.key>


More information about the Users mailing list