[Swan] private key for cert Thor not found in local cache; loading from NSS DB

rayv33n rayv33n at gmail.com
Sun Oct 7 19:05:06 UTC 2018


Followed all your suggestions and the connection information shows the that
the oppo sees that IP addresses across the connection down to the
%fromcert. What's different this time is the +MS+S=C which I have no idea
what that is. I blew away the /etc/ipsec.d/*.db and when back to the
instruction on how to create it.

oppo_instantiate() instantiated "[1] ...XX.XXX.XXX.205"private#0.0.0.0/0:
10.0.0.47[MS+S=C]---13.57.200.87...XX.XXX.XXX.205[%fromcert,+MC+S=C]

Oct  7 18:54:28.198237: | private key for cert Thor not found in local
cache; loading from NSS DB
Oct  7 18:54:28.202605: | ikev2_child_sa_respond returned
STF_FAIL+v2N_TS_UNACCEPTABLE
Oct  7 18:54:28.202620: | ikev2_parent_inI2outR2_continue_tail returned
STF_FAIL+v2N_TS_UNACCEPTABLE
Oct  7 18:54:28.202628: "private#0.0.0.0/0"[1] ...XX.XXX.XXX.205 #1:
responding to AUTH message (ID 1) from XX.XXX.XXX.205:47402 with encrypted
notification AUTHENTICATION_FAILED
-------------------------

root at thor:/etc/ipsec.d# cat nsspassword
NSS Certificate DB:12345678
-------------------------
root at thor:/etc/ipsec.d# certutil -d sql:/etc/ipsec.d/ -L

Certificate Nickname                                         Trust
Attributes

SSL,S/MIME,JAR/XPI
Thor                                                        u,u,u
5 Dev CA                                                CT,,
VPN Subordinate                                    CT,,
-------------------------

root at thor:/etc/ipsec.d# certutil -d sql:/etc/ipsec.d/ -K
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa      e392b3b8e90f3629e6fefa741f2c89db4a5935e0   Thor

-------------------------
conn private
        # IPsec mandatory
    hostaddrfamily=ipv4
        rightrsasigkey=%cert
        right=%opportunisticgroup
        rightid=%fromcert
    rightca=%same
    rightaddresspool=100.64.1.0-100.64.1.254
    #rightcat=yes
           #rightmodecfgclient=yes
    #leftsubnet=10.0.0.47/32
    left=%defaultroute
    leftcert=Thor
    leftsendcert=always
        leftid=%cert
        leftnexthop=13.57.200.87
    #leftrsasigkey=%cert
    narrowing=yes
        type=tunnel
        ikev2=insist
    negotiationshunt=hold
        failureshunt=drop
        keyingtries=0
        retransmit-timeout=3s
        auto=ondemand
    ike=aes256-sha1;modp2048
    phase2alg=aes256-sha1;modp2048
-------------------------
root at thor:/etc/ipsec.d# ipsec auto --listcerts
000
000 List of X.509 End Certificates:
000
000 End certificate "Thor" - SN: 0x73f1b651ab0f019d
000   subject: C=US, ST=CA, L=Palo Alto, O=mycompany, OU=5, CN=Thor, E=
admin at mycompany.com
000   issuer: CN= VPN Subordinate
000   not before: Fri Sep 28 05:50:47 2018
000   not after: Sun Sep 27 05:50:47 2020
000   2048 bit RSA: has private key
root at thor:/etc/ipsec.d# ipsec auto --listall
000
000 List of Public Keys:
000
000 Oct 07 18:54:28 2018, 2048 RSA Key AwEAAbcJJ (no private key), until
Aug 25 18:23:07 2020 ok
000        ID_DER_ASN1_DN 'C=US, ST=CA, L=Palo Alto, O=mycompany, OU=,
CN=ipsechost1, E=admin at mycompany.com'
000        Issuer 'CN= VPN Subordinate'
000 Oct 07 18:54:28 2018, 2048 RSA Key AwEAAbcJJ (no private key), until
Aug 25 18:23:07 2020 ok
000        ID_USER_FQDN 'admin at mycompany.com'
000        Issuer 'CN= VPN Subordinate'
000 Oct 07 18:54:20 2018, 2048 RSA Key AwEAAeaaN (has private key), until
Sep 27 05:50:47 2020 ok
000        ID_DER_ASN1_DN 'C=US, ST=CA, L=Palo Alto, O=mycompany, OU=5,
CN=Thor, E=admin at mycompany.com'
000        Issuer 'CN= VPN Subordinate'
000
000 List of Pre-shared secrets (from /etc/ipsec.secrets)
000
000     0: RSA (none) (none)
000
000 List of X.509 End Certificates:
000
000 End certificate "Thor" - SN: 0x73f1b651ab0f019d
000   subject: C=US, ST=CA, L=Palo Alto, O=mycompany, OU=5, CN=Thor, E=
admin at mycompany.com
000   issuer: CN= VPN Subordinate
000   not before: Fri Sep 28 05:50:47 2018
000   not after: Sun Sep 27 05:50:47 2020
000   2048 bit RSA: has private key
000
000 List of X.509 CA Certificates:
000
000 CA certificate " VPN Subordinate" - SN: 0x18f0fd4df52ebd9c
000   subject: CN= VPN Subordinate
000   issuer: CN= Dev CA
000   not before: Thu Aug 02 02:00:42 2018
000   not after: Mon May 05 00:00:00 2025
000   4096 bit RSA
000
000 Root CA certificate " Dev CA" - SN: 0x09f888ec6ccbdc39
000   subject: CN= Dev CA
000   issuer: CN= Dev CA
000   not before: Tue Jun 26 04:30:58 2018
000   not after: Tue Jun 25 00:00:00 2030
000   2048 bit RSA
000
000 List of CRLs:


On Sun, Oct 7, 2018 at 10:25 AM rayv33n <rayv33n at gmail.com> wrote:

> HI Paul,
>
> Thanks for the response! I've been doing what you said users would be
> doing in your video on OE which is copying configs off the internet and
> trying different unrelated things. :D I'm guilty!
>
> The regular config I have work if there is not NAT involved. Same config
> applies to all hosts in the lab and they work beautifully. Then I built an
> AWS instanced and tried it. Same Ubuntu systems, same everything but the
> only difference is AWS NAT and yes the lab systems are NAT as well.
>
> This is what led to my confusion about the cause. I'll have a look at the
> pkcs12 import process and report back, it's possible that I screwed that up
> but in general I've been using the CN=hostname as the friendly name on
> import so it make it easier to remember. I also wanted to build the worse
> case scenario so when I showcased the demo I could start driving the
> narrative away from traditional firewalls/NAT/v4 and move it towards no-NAT
> and v6. That value of moving away from NAT and v4 is it's less complex to
> manage assuming v6 will do OE because the configuration can be a repeatable
> standard with no manually edits.
>
> Let me do some checking and get back to you on the rest below.
>
>
> On Fri, Oct 5, 2018 at 11:49 AM Paul Wouters <paul at nohats.ca> wrote:
>
>> On Thu, 4 Oct 2018, rayv33n wrote:
>>
>> > No sure that to make of this message. Originally I thought it was a
>> warning letting me know that after restarting ipsec that cache was check
>> > and then private key
>>
>> The leftcert= entry has to match the "friendly name" that normally comes
>> from importing the PKCS#12. I assume it can also be set when importing
>> the signed certificate back into the NSS db.
>>
>> > I'm fairly certain this is a NAT issue but tcpdump
>> > show 4500/UDP being used immediately after initial handshake.
>>
>> The cert errors have nothing to do with NAT. The NAT will only cause
>> changes in the final IP addreses used for the src-dst of the IPsec
>> tunnel. It does not affect authentication.
>>
>>
>> > where to look After days of
>> > unsuccessfully troubleshoot I'm finally coming to the list. Goals it so
>> make a mesh network hosts only and not servers across lots of divers
>> > infrastructure.
>> >
>> > network setup. ipsechost1(172.16.1.61)---> Netgate(76.1XX.2XX.2XX.2xx)
>> <--> AWS(13.57.XXX.XX) --> Thor(10.0.0.47)
>>
>> So both ends are behind NAT? That gets a lot trickier, because both ends
>> cannot request an address and offer one from a pool. Or is one of these
>> perhaps a static port forward?
>>
>> > Using NSS of course with /etc/ipsec.d/nsspassword(NSS Certificate
>> DB:12345678)
>>
>> so the configuration differs whether or not you need to support NAT, and
>> whether to support is as the client behind NAT or the server (not NATed
>> or perhaps a static port forward)
>>
>> > #Thor god of thunder
>> > conn private
>> >         # IPsec mandatory
>> >        hostaddrfamily=ipv4
>> >         rightrsasigkey=%cert
>> >         right=%opportunisticgroup
>> >         rightid=%fromcert
>> >         rightca=%same
>> >         rightmodecfgclient=yes
>> >         leftsubnet=10.0.0.47/32
>>
>> You should not specify any subnet= because the Opportunistic mechanism
>> fills that in when instantiating the connection. This conn private is
>> a template, so it can never have all the right addresses pre-filled in.
>>
>> >         left=%defaultroute
>> >         leftcert=Thor
>> >         leftsendcert=always
>> >         leftid=%cert
>>
>> That is %fromcert, not %cert
>>
>> >         leftnexthop=13.57.xxx.xx
>>
>> don't use any nexthop's.
>>
>> >         leftrsasigkey=%cert
>> >         #narrowing=yes
>>
>> You need narrowing=yes if you can be behind NAT. It will allow the
>> server to narrow you down. For the server side, you then need to
>> specify a rightaddresspool= (used for the "NAT within IPsec", so you
>> can pick eg 100.64.0.0/16)
>>
>> >         type=tunnel
>> >         ikev2=insist
>> >         negotiationshunt=hold
>> >         failureshunt=drop
>> >         keyingtries=0
>> >         retransmit-timeout=3s
>> >         auto=ondemand
>> >         ike=aes256-sha1;modp2048
>> >         phase2alg=aes256-sha1;modp2048
>>
>> will libreswan everywhere, it is better to leave out ike= esp= and
>> phase2alg= lines and rely on the buildin defaults. It will make
>> upgrades in the future easier.
>>
>> > Oct  4 14:38:50.506799: "private#0.0.0.0/0"[1] ...76.1XX.2XX.2XX.2xx
>> #1: certificate verified OK:
>> > E=admin at mycompany.com,CN=ipsechost1,OU=Level5,O=mycompany,L=Palo
>> Alto,ST=CA,C=US
>> > Oct  4 14:38:50.507848: "private#0.0.0.0/0"[1] ...76.1XX.2XX.2XX.2xx
>> #1: Authenticated using RSA
>> >  private key for cert Thor not found in local cache; loading from NSS DB
>> >  searching for certificate PKK_RSA:AwEAAeaaN vs PKK_RSA:AwEAAeaaN
>>
>> It found the one it wanted but no private key. This problem is unrelated
>> to the Opportunistic configuration. You would have the same with a
>> static vpn tunnel.
>>
>> Paul
>>
>
>
> --
> You are FREE to become a slave
>
> Key ID: 9A452ABAA4593489
> Finger Print: 7A8A 5849 ED44 52B1 0D8A EDAC 9A45 2ABA A459 3489
> *Pub Key: *
> http://pgp.mit.edu:11371/pks/lookup?search=rayv33n%40gmail.com&op=index
>


-- 
You are FREE to become a slave

Key ID: 9A452ABAA4593489
Finger Print: 7A8A 5849 ED44 52B1 0D8A EDAC 9A45 2ABA A459 3489
*Pub Key: *
http://pgp.mit.edu:11371/pks/lookup?search=rayv33n%40gmail.com&op=index
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20181007/cfbd25dc/attachment-0001.html>


More information about the Swan mailing list