<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">That is a configuration mismatch. So the end that is doing the wrong intention should change - I can’t tell which end that is<br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Oct 26, 2020, at 11:26, Brian McKee <raydude@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi Paul,<div>I have to admit, I misunderstood way back in the beginning and made too many changes to the ebuild. I thought that the whole config directory had moved, when it was only the nss directory. I have sorted that out now. All I had to do was have the ebuild create the /var/lib/ipsec/nss directory just like you suggested.</div><div><br></div><div>All that is sorted out now. Here is the latest error message. </div><div><br></div><div>Oct 26 08:11:27.500126: loading secrets from "/etc/ipsec.secrets"<br>Oct 26 08:11:27.500164: loading secrets from "/etc/ipsec.d/ipsec.nm-l2tp.secrets"<br>Oct 26 08:11:27.511475: added IKEv1 connection "9a088450-2a7b-4012-befe-facf564c77e0"<br>Oct 26 08:11:27.522480: "9a088450-2a7b-4012-befe-facf564c77e0" #1: initiating IKEv1 Main Mode connection<br>Oct 26 08:11:27.522658: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent Main Mode request<br>Oct 26 08:11:28.023076: "9a088450-2a7b-4012-befe-facf564c77e0" #1: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response<br>Oct 26 08:11:28.029379: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent Main Mode I2<br>Oct 26 08:11:28.530045: "9a088450-2a7b-4012-befe-facf564c77e0" #1: STATE_MAIN_I2: retransmission; will wait 0.5 seconds for response<br>Oct 26 08:11:28.593729: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent Main Mode I3<br>Oct 26 08:11:28.689015: "9a088450-2a7b-4012-befe-facf564c77e0" #1: Peer ID is ID_IPV4_ADDR: '[[server ip_address]]'<br>Oct 26 08:11:28.689218: "9a088450-2a7b-4012-befe-facf564c77e0" #1: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA1 group=MODP2048}<br>Oct 26 08:11:28.689336: "9a088450-2a7b-4012-befe-facf564c77e0" #2: initiating Quick Mode PSK+ENCRYPT+PFS+UP+IKEV1_ALLOW+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:84d31f03 proposal=AES_CBC_256-HMAC_SHA1_96, AES_CBC_128-HMAC_SHA1_96, 3DES_CBC-HMAC_SHA1_96 pfsgroup=MODP2048}<br>Oct 26 08:11:28.692241: "9a088450-2a7b-4012-befe-facf564c77e0" #2: sent Quick Mode request<br>Oct 26 08:11:29.193066: "9a088450-2a7b-4012-befe-facf564c77e0" #2: STATE_QUICK_I1: retransmission; will wait 0.5 seconds for response<br>Oct 26 08:11:29.586945: "9a088450-2a7b-4012-befe-facf564c77e0" #2: NAT-Traversal: received 2 NAT-OA. Ignored because peer is not NATed<br>Oct 26 08:11:29.587049: "9a088450-2a7b-4012-befe-facf564c77e0" #2: our client subnet returned doesn't match my proposal - us: [[machine home net IP addy]]/32 vs them: [[my internet IP address]]/32<br>Oct 26 08:11:29.587089: "9a088450-2a7b-4012-befe-facf564c77e0" #2: sending encrypted notification INVALID_ID_INFORMATION to [[server ip_address]]:4500<br>Oct 26 08:11:29.587339: "9a088450-2a7b-4012-befe-facf564c77e0" #2: deleting state (STATE_QUICK_I1) aged 0.898044s and NOT sending notification<br>Oct 26 08:11:29.587451: "9a088450-2a7b-4012-befe-facf564c77e0" #2: ERROR: netlink response for Del SA esp.cfdd97dd@[[server ip_address]] included errno 3: No such process<br>Oct 26 08:11:43.789943: "9a088450-2a7b-4012-befe-facf564c77e0": terminating SAs using this connection<br>Oct 26 08:11:43.790008: "9a088450-2a7b-4012-befe-facf564c77e0" #1: deleting state (STATE_MAIN_I4) aged 16.267541s and sending notification<br></div><div><br></div><div>This looks like a configuration error as the remote host is confused about my home network IP address and my internet IP address.</div><div><br></div><div>We're close, I think. Thanks again for your help.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 26, 2020 at 7:04 AM Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 25 Oct 2020, Brian McKee wrote:<br>
<br>
> THANKS! That was a great idea!I found this in /var/log/pluto.log: (Let me know if you need to see more, this is<br>
> just the end of it)<br>
<br>
> Oct 25 15:47:46.268455: "9a088450-2a7b-4012-befe-facf564c77e0" #1: initiating IKEv1 Main Mode connection<br>
> Oct 25 15:47:46.268593: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent Main Mode request<br>
> Oct 25 15:47:46.339726: "9a088450-2a7b-4012-befe-facf564c77e0" #1: Can't authenticate: no preshared key found<br>
> for `10.1.10.221' and `[[IP_ADDRESS]]'. Attribute OAKLEY_AUTHENTICATION_METHOD<br>
<br>
Your machine cannot find it's own PSK ?<br>
<br>
Normally, NetworkManager writes a secrets file that is read via the<br>
include statement in /etc/ipsec.secrets for /etc/ipsec.d/*.secrets<br>
and then it runs "ipsec secrets" to re-read it, and it deletes the file<br>
again.<br>
<br>
Perhaps libreswan was compiled with ipsecddir at a different location?<br>
<br>
> Based on this, I guess there's a pre-shared-key issue. But I set that in kde's network manager's systems<br>
> settings module. Is it possible that the PSK has changed location in the conf files?<br>
<br>
check if you have an /etc/ipsec.secrets file and if it has an include<br>
line for /etc/ipsec.d/*.secrets ?<br>
<br>
You can always drop in a permanent file or entry in /etc/ipsec.secrets<br>
with:<br>
<br>
0.0.0.0 [[IP_ADDRESS]] : PSK "yourstrongsecret"<br>
<br>
Paul<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">-- Consciousness moves everything.</div>
</div></blockquote></body></html>