P.S.
It seems that IPSEC is established, and a transport connection:
Nov 24 15:16:18.322599: | pstats #14 ikev1.ipsec established
Nov 24 15:16:18.322609: | NAT-T: encaps is 'auto'
Nov 24 15:16:18.322617: "L2TP-PSK-noNAT"[7] 193.198.186.218 #14:
STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0xbd9d07f4
<0x935a0ca5 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=none DPD
but then, after receiving first encrypted packet, pluto spuriously
decides to delete, "down" the connection and "unroute" it:
Nov 24 15:16:53.359857: | State DB: found IKEv1 state #13 in MAIN_R3
(find_v1_info_state)
Nov 24 15:16:53.359876: | start processing: state #13 connection
"L2TP-PSK-noNAT"[7] 193.198.186.218 from 193.198.186.218:500 (in
process_v1_packet() at ikev1.c:1347)
Nov 24 15:16:53.359946: | #13 is idle
Nov 24 15:16:53.359963: | #13 idle
Nov 24 15:16:53.359977: | received encrypted packet from 193.198.186.218:500
Nov 24 15:16:53.360029: | got payload 0x100 (ISAKMP_NEXT_HASH) needed:
0x100 opt: 0x0
Nov 24 15:16:53.360046: | ***parse ISAKMP Hash Payload:
Nov 24 15:16:53.360056: | next payload type: ISAKMP_NEXT_D (0xc)
Nov 24 15:16:53.360067: | length: 24 (00 18)
Nov 24 15:16:53.360080: | got payload 0x1000 (ISAKMP_NEXT_D) needed:
0x0 opt: 0x0
Nov 24 15:16:53.360090: | ***parse ISAKMP Delete Payload:
Nov 24 15:16:53.360103: | next payload type: ISAKMP_NEXT_NONE (0x0)
Nov 24 15:16:53.360113: | length: 16 (00 10)
Nov 24 15:16:53.360122: | DOI: ISAKMP_DOI_IPSEC (0x1)
Nov 24 15:16:53.360133: | protocol ID: 3 (03)
Nov 24 15:16:53.360145: | SPI size: 4 (04)
Nov 24 15:16:53.360156: | number of SPIs: 1 (00 01)
Nov 24 15:16:53.360168: | removing 8 bytes of padding
Nov 24 15:16:53.360246: | informational HASH(1):
Nov 24 15:16:53.360263: | 2d d3 57 39 ab 57 ef 6d 30 6a 00 36 cc 47
23 57
Nov 24 15:16:53.360274: | 88 1e 35 78
Nov 24 15:16:53.360284: | received 'informational' message HASH(1) data ok
Nov 24 15:16:53.360295: | parsing 4 raw bytes of ISAKMP Delete Payload
into SPI
Nov 24 15:16:53.360303: | SPI
Nov 24 15:16:53.360330: | bd 9d 07 f4
Nov 24 15:16:53.360339: | FOR_EACH_STATE_... in find_phase2_state_to_delete
Nov 24 15:16:53.360358: | start processing: connection
"L2TP-PSK-noNAT"[7] 193.198.186.218 (BACKGROUND) (in accept_delete() at
ikev1_main.c:2488)
Nov 24 15:16:53.360377: "L2TP-PSK-noNAT"[7] 193.198.186.218 #13:
received Delete SA(0xbd9d07f4) payload: deleting IPsec State #14
Nov 24 15:16:53.360393: | pstats #14 ikev1.ipsec deleted completed
I seem to be stuck here, I don't know how to debug connection.
Please help.
Kind regards,
Mirsad Todorovac
On 11/24/2021 2:42 PM, Mirsad Goran Todorovac wrote:
Dear Mr. Wouters,
I have upgraded libreswan to enable bug fixes from an earlier email
I've sent.
Now I've lost even the basic IKEv1 L2TP over IPSEC PSK connectivity.
This is very embarrassing as I've
spent four days and I have nothing to show to superiors.
Please help if you can.
It seems that PSK is accepted and verified, IPSEC session established
and transport connection brought up,
but I can't seem to realize from the pluto session log what went wrong.
Here is my "/etc/ipsec.d/l2tp-psk.conf":
# conn L2TP-PSK-NAT
# rightsubnet=vhost:%priv
# also=L2TP-PSK-common
conn L2TP-PSK-noNAT
rightsubnet=vhost:%no
also=L2TP-PSK-common
conn L2TP-PSK-common
# Use a Preshared Key. Disable Perfect Forward Secrecy.
authby=secret
pfs=no
auto=add
keyingtries=3
# we cannot rekey for %any, let client rekey
rekey=no
# Apple iOS doesn't send delete notify so we need dead peer
detection
# to detect vanishing clients
dpddelay=10
dpdtimeout=30
dpdaction=clear
# Set ikelifetime and keylife to same defaults windows has
ikelifetime=8h
keylife=1h
ikev2=never
# l2tp-over-ipsec is transport mode
type=transport
#
# left will be filled in automatically with the local address
of the default-route interface (as determined at IPsec startup time).
left=%defaultroute
#
# For updated Windows 2000/XP clients,
# to support old clients as well, use leftprotoport=17/%any
leftprotoport=17/1701
#
# The remote user.
#
right=%any
# Using the magic port of "%any" means "any one single port".
This is
# a work around required for Apple OSX clients that use a randomly
# high port.
rightprotoport=17/%any
The error reported is:
The pluto session log is:
https://domac.alu.hr/mtodorov/l2tp-ipsec-psk-noNAT3-20211124.log
Once again, thank you for the previous advice and the VPN connection
started working.
Then I tried to enable IKEv2 with certificates, and upgraded to
libreswan-4.5 to get to bug fix.
Now I am trying the latest 3.x version, 3.32, but no luck.
Thank you very much for all help.
I am reading the ipsec.conf.5 manual, but it will take some time
before my learning curve adapts. :-(
Kind regards,
Mirsad Todorovac
--
Mirsad Goran Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
--
Mirsad Goran Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
