Bug #2190
SPI of outbound SA is 0 if charon.prefer_configured_proposals is disabled
Description
I have currently compiled StrongSwan 5.5.1 using Mingw64 6.2.0 with msys and openssl-1.0.1u.
I currently do not have the skill set to go any further with this as my programming knowledge is limited but
am willing to help where I can.
This is what I have found.
There is a problem with charon-svc when it tries to add Outbound SA Context using (IPsecSaContextAddOutbound0) found
in file /src/libcharon/plugins/kernel_wfp/kernel_wfp_ipsec.c (line 1086)
(15[KNL] <station|1> adding outbound WFP SA failed: 0x00000057)
The inbound rules seem to be added correctly (can not verify this as the get removed after the error occurs)
I noticed that there was a change recently to StrongSwan (5.5.1) to only add the inbound rules
[[https://wiki.strongswan.org/versions/63]] (could this have introduced the problem)
If I add the option to "policies = no" to a Children section
The tunnel exchange completes successfully but the tunnel of course is not working.
NOTE: I notices an entry in the log that look unusual but since my knowledge of the
problem is limited it might be nothing. (the entry of all zeros seem odd)
Dec 12 12:45:35 15[CHD] <station|1> SPI 0x00000000, src 10.42.108.50 dst 10.42.108.22
Here is a cut from the error log (I have attached the full log as well as the configuration files).
Dec 12 12:45:35 15[CHD] <station|1> adding inbound ESP SA Dec 12 12:45:35 15[CHD] <station|1> SPI 0xc6d5a5e8, src 10.42.108.22 dst 10.42.108.50 Dec 12 12:45:35 15[CHD] <station|1> adding outbound ESP SA Dec 12 12:45:35 01[JOB] next event in 1s 317ms, waiting Dec 12 12:45:35 15[CHD] <station|1> SPI 0x00000000, src 10.42.108.50 dst 10.42.108.22 Dec 12 12:45:35 15[KNL] <station|1> getting a local address in traffic selector 10.42.78.0/24 Dec 12 12:45:35 15[KNL] <station|1> using host 10.42.78.1 Dec 12 12:45:35 15[KNL] <station|1> adding outbound WFP SA failed: 0x00000057 Dec 12 12:45:35 04[JOB] watcher got notification, rebuilding Dec 12 12:45:35 15[KNL] <station|1> getting a local address in traffic selector 10.42.78.0/24 Dec 12 12:45:35 04[JOB] watching 288 for reading Dec 12 12:45:35 15[KNL] <station|1> using host 10.42.78.1 Dec 12 12:45:35 04[JOB] watching 428 for reading Dec 12 12:45:35 04[JOB] watching 428 for writing Dec 12 12:45:35 04[JOB] watcher going to poll() 3 fds Dec 12 12:45:35 04[JOB] watcher got notification, rebuilding Dec 12 12:45:35 04[JOB] watching 288 for reading Dec 12 12:45:35 04[JOB] watching 428 for reading Dec 12 12:45:35 15[IKE] <station|1> unable to install IPsec policies (SPD) in kernel Dec 12 12:45:35 04[JOB] watching 428 for writing Dec 12 12:45:35 04[JOB] watcher going to poll() 3 fds Dec 12 12:45:35 15[IKE] <station|1> failed to establish CHILD_SA, keeping IKE_SA Dec 12 12:45:35 04[JOB] watched FD 428 ready to write Dec 12 12:45:35 15[IKE] <station|1> received AUTH_LIFETIME of 10161s, scheduling reauthentication in 8721s Dec 12 12:45:35 15[IKE] <station|1> reinitiating already active tasks Dec 12 12:45:35 01[JOB] next event in 1s 286ms, waiting Dec 12 12:45:35 15[IKE] <station|1> CHILD_CREATE task Dec 12 12:45:35 04[JOB] watching 288 for reading Dec 12 12:45:35 15[ENC] <station|1> added payload of type DELETE to message Dec 12 12:45:35 15[IKE] <station|1> sending DELETE for ESP CHILD_SA with SPI c6d5a5e8
History
#1 Updated by Tobias Brunner over 8 years ago
- Tracker changed from Issue to Bug
- Subject changed from Strongswan on Windows to SPI of outbound SA is 0 if charon.prefer_configured_proposals is disabled
- Status changed from New to Feedback
- Assignee set to Tobias Brunner
- Target version set to 5.5.2
I noticed that there was a change recently to StrongSwan (5.5.1) to only add the inbound rules
[[https://wiki.strongswan.org/versions/63]] (could this have introduced the problem)
No, that's not related (it's a change regarding FWD policies, not SAs).
If I add the option to "policies = no" to a Children section
The tunnel exchange completes successfully but the tunnel of course is not working.
That's odd, as it shouldn't affect the SAs.
NOTE: I notices an entry in the log that look unusual but since my knowledge of the
problem is limited it might be nothing. (the entry of all zeros seem odd)
Definitely looks suspicious. There is apparently an SPI in the proposal:
Dec 12 12:45:35 15[ENC] <station|1> parsing PROPOSAL_SUBSTRUCTURE payload, 100 bytes left ... Dec 12 12:45:35 15[ENC] <station|1> parsing rule 7 SPI Dec 12 12:45:35 15[ENC] <station|1> => 4 bytes @ 0x000000000031ccc0 Dec 12 12:45:35 15[ENC] <station|1> 0: CF 98 1E D7 ....
So the SPI should definitely not suddenly become 0.
But I think I have identified the bug. It is caused by the setting charon.prefer_configured_proposals = no. With this, the SPI is currently copied from the wrong proposal (the configured one, that has no SPI set).
I pushed a fix for this to the 2190-prefer-configured-spi branch. As a workaround, enable the setting above (and maybe change the configured proposals).
#2 Updated by vlagnar vlagnar over 8 years ago
- File swanctl.conf swanctl.conf added
- File strongswan.conf strongswan.conf added
- File charon-svc-log.txt charon-svc-log.txt added
- File swanctl_output.txt swanctl_output.txt added
I am connected now (Thanks Tobias Brunner!)
Removed the (prefer_configured_proposals) option and now it connects.
I seem to be getting a routing issue (the SPI seems to be zero again.)
24[KNL] IPsec kernel drop: 10.42.78.1/32[icmp] === 10.110.50.2/32[icmp], error 0
xc0360007, SPI 0x00000000, in filterId 2479820
During my ping test (10.42.78.1 --> 10.110.50.2) the device (10.110.50.2) inside the network replies to the packet but on the return route it seems that I get the above error.
My current configuration is (windows machine)
Windows 7 Machine
[Loopback (10.42.78.1/24)] --> GATEWAY UNIT --> (10.110.50.0/24 netwk)
[Local (10.42.108.50/24)]
[Connected 10.42.78.1 with
10.42.108.50 using Internet
connection sharing]
Thanks again and MERRY CHRISTMAS!!!
#3 Updated by vlagnar vlagnar over 8 years ago
I think this is related to the following. Has anybody made any progress is this area?
[[https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-wfp]]
he kernel raises a STATUS_IPSEC_CLEAR_TEXT_DROP event if such a packet is received. The Microsoft Knowledge Base entry KB2502685 exactly describes this issue and provides a hotfix, but is related to a Forefront TMG server. It is currently not clear if the same issue applies to the Windows 7 product family or if it can be worked around from userland.
#4 Updated by Tobias Brunner over 8 years ago
- Category changed from kernel to libcharon
- Status changed from Feedback to Closed
#5 Updated by Tobias Brunner over 8 years ago
- Resolution set to Fixed