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

[rayv33n]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20181007/10d66dc4/attachment.html>