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: [email protected],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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
