[strongSwan] no IDr configured, fall back on IP address - revisit
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Wed Oct 30 16:08:05 CET 2019
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
>
-------------- 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/7c81250b/attachment-0001.sig>
More information about the Users
mailing list