[Swan] Issue with networkmanager and l2tp

Mon Oct 26 18:08:50 UTC 2020

Hi Paul and Doug,

I couldn't figure out how to get 4.1 to work and went back to libreswan
3.32.

I imagine I will have to face this again soon...

Thanks again for trying to help me.

On Mon, Oct 26, 2020 at 8:54 AM Paul Wouters <paul at nohats.ca> wrote:

> That is a configuration mismatch. So the end that is doing the wrong
> intention should change - I can’t tell which end that is
>
> Sent from my iPhone
>
> On Oct 26, 2020, at 11:26, Brian McKee <raydude at gmail.com> wrote:
>
> 
> Hi Paul,
> 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.
>
> All that is sorted out now. Here is the latest error message.
>
> Oct 26 08:11:27.500126: loading secrets from "/etc/ipsec.secrets"
> Oct 26 08:11:27.500164: loading secrets from
> "/etc/ipsec.d/ipsec.nm-l2tp.secrets"
> Oct 26 08:11:27.511475: added IKEv1 connection
> "9a088450-2a7b-4012-befe-facf564c77e0"
> Oct 26 08:11:27.522480: "9a088450-2a7b-4012-befe-facf564c77e0" #1:
> initiating IKEv1 Main Mode connection
> Oct 26 08:11:27.522658: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent
> Main Mode request
> Oct 26 08:11:28.023076: "9a088450-2a7b-4012-befe-facf564c77e0" #1:
> STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response
> Oct 26 08:11:28.029379: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent
> Main Mode I2
> Oct 26 08:11:28.530045: "9a088450-2a7b-4012-befe-facf564c77e0" #1:
> STATE_MAIN_I2: retransmission; will wait 0.5 seconds for response
> Oct 26 08:11:28.593729: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent
> Main Mode I3
> Oct 26 08:11:28.689015: "9a088450-2a7b-4012-befe-facf564c77e0" #1: Peer ID
> is ID_IPV4_ADDR: '[[server ip_address]]'
> 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}
> 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}
> Oct 26 08:11:28.692241: "9a088450-2a7b-4012-befe-facf564c77e0" #2: sent
> Quick Mode request
> Oct 26 08:11:29.193066: "9a088450-2a7b-4012-befe-facf564c77e0" #2:
> STATE_QUICK_I1: retransmission; will wait 0.5 seconds for response
> Oct 26 08:11:29.586945: "9a088450-2a7b-4012-befe-facf564c77e0" #2:
> NAT-Traversal: received 2 NAT-OA. Ignored because peer is not NATed
> 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
> Oct 26 08:11:29.587089: "9a088450-2a7b-4012-befe-facf564c77e0" #2: sending
> encrypted notification INVALID_ID_INFORMATION to [[server ip_address]]:4500
> Oct 26 08:11:29.587339: "9a088450-2a7b-4012-befe-facf564c77e0" #2:
> deleting state (STATE_QUICK_I1) aged 0.898044s and NOT sending notification
> 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
> Oct 26 08:11:43.789943: "9a088450-2a7b-4012-befe-facf564c77e0":
> terminating SAs using this connection
> Oct 26 08:11:43.790008: "9a088450-2a7b-4012-befe-facf564c77e0" #1:
> deleting state (STATE_MAIN_I4) aged 16.267541s and sending notification
>
> This looks like a configuration error as the remote host is confused about
> my home network IP address and my internet IP address.
>
> We're close, I think. Thanks again for your help.
>
> On Mon, Oct 26, 2020 at 7:04 AM Paul Wouters <paul at nohats.ca> wrote:
>
>> On Sun, 25 Oct 2020, Brian McKee wrote:
>>
>> > 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
>> > just the end of it)
>>
>> > Oct 25 15:47:46.268455: "9a088450-2a7b-4012-befe-facf564c77e0" #1:
>> initiating IKEv1 Main Mode connection
>> > Oct 25 15:47:46.268593: "9a088450-2a7b-4012-befe-facf564c77e0" #1: sent
>> Main Mode request
>> > Oct 25 15:47:46.339726: "9a088450-2a7b-4012-befe-facf564c77e0" #1:
>> Can't authenticate: no preshared key found
>> > for `10.1.10.221' and `[[IP_ADDRESS]]'.  Attribute
>> OAKLEY_AUTHENTICATION_METHOD
>>
>> Your machine cannot find it's own PSK ?
>>
>> Normally, NetworkManager writes a secrets file that is read via the
>> include statement in /etc/ipsec.secrets for /etc/ipsec.d/*.secrets
>> and then it runs "ipsec secrets" to re-read it, and it deletes the file
>> again.
>>
>> Perhaps libreswan was compiled with ipsecddir at a different location?
>>
>> > Based on this, I guess there's a pre-shared-key issue. But I set that
>> in kde's network manager's systems
>> > settings module. Is it possible that the PSK has changed location in
>> the conf files?
>>
>> check if you have an /etc/ipsec.secrets file and if it has an include
>> line for /etc/ipsec.d/*.secrets ?
>>
>> You can always drop in a permanent file or entry in /etc/ipsec.secrets
>> with:
>>
>>         0.0.0.0  [[IP_ADDRESS]] : PSK "yourstrongsecret"
>>
>> Paul
>>
>
>
> --
> -- Consciousness moves everything.
>
>

-- 
-- Consciousness moves everything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20201026/04dc9d9b/attachment-0001.html>