[Swan] Problem with SAupdate when SA does not exist in the kernel

Paul Wouters paul at nohats.ca
Tue Sep 24 17:34:08 EEST 2013


On Tue, 24 Sep 2013, Mattias Walström wrote:

> Sorry for the delayed reply, have had some problems with the mailserver.
>
> I have done a lot of tests, the only thing that seems to help when the 
> problem occurs to reboot the initiator or restart pluto on the initator.
>
> What my patch actually does is handle the error codes from the kernel, when 
> openswan fails to update an SA that (for some reason) does not exist in the 
> kernel, handle the error code and insert the SA in the kernel as a new SA.

Thanks for the feedback. You are correct. The patch has been merged and
will be in libreswan 3.6.

Thanks for the explanation!

Paul

> Mattias
>
> On 09/12/2013 04:26 PM, Paul Wouters wrote:
>> On Thu, 12 Sep 2013, Mattias Walström wrote:
>> 
>>> I have discovered a problem with a non-clean restart of the responder, I 
>>> have 14 tunnels configured between one initiator and one responder. When I 
>>> do a "killall -9 pluto" on the responder, it will force pluto to exit, 
>>> without closing the connection. When pluto starts again I will get an 
>>> error on the initiator for some of the tunnels (one to three tunnels will 
>>> not come back up at all):
>>> 
>>> Jan  5 16:46:50 i pluto[2593]: | setup_half_ipsec_sa() hit fail:
>>> Jan  5 16:46:50 i pluto[2593]: "ipsec7" #23: ERROR: netlink response for 
>>> Add SA esp.17d54247 at 198.18.106.2 included errno 3: No such process
>> 
>> There are some known XFRM/NETKEY issues with unclean states in the esp4
>> module when there is no proper cleanup. I believe Paul Moore fixed these
>> but its still making its way to upstream linux.
>> 
>> Could you repeat the test, but after you killall -9 pluto, _also_ reboot
>> the machine?
>> 
> Reboot on the responder does not help, reboot on the initiator helps, but 
> that is not really a solution.
>
>>> To solve this I have made sure that update will not fail even if there has 
>>> been a problem adding the SA, but I am unsure if this is a proper 
>>> solution.
>>> 
>>> I have seen the same problem for both libreswan 3.5 and openswan 2.6.38, 
>>> but I have only tested to patch for openswan.
>> 
>> So what does this do? Fool pluto into thinking the IPsec SA is up, while
>> you are leaking plaintext? I'm confused....
>> 
>> Paul
>> 
>>> Regards
>>> Mattias
>>> 
>>> Index: openswan-2.6.38/programs/pluto/kernel_netlink.c
>>> ===================================================================
>>> --- openswan-2.6.38.orig/programs/pluto/kernel_netlink.c 2013-09-12 
>>> 11:35:45.853061103 +0200
>>> +++ openswan-2.6.38/programs/pluto/kernel_netlink.c 2013-09-12 
>>> 12:09:50.948600196 +0200
>>> @@ -393,6 +393,7 @@
>>>         , description, text_said
>>>         , -rsp.e.error
>>>         , strerror(-rsp.e.error));
>>> +    errno = -rsp.e.error;
>>>     return FALSE;
>>>     }
>>> 
>>> @@ -794,6 +795,7 @@
>>>     } req;
>>>     struct rtattr *attr;
>>>     struct aead_alg *aead;
>>> +    int ret;
>>>
>>>     memset(&req, 0, sizeof(req));
>>>     req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
>>> @@ -990,8 +992,11 @@
>>>         attr = (struct rtattr *)((char *)attr + attr->rta_len);
>>>    }
>>> #endif
>>> +    ret = send_netlink_msg(&req.n, NULL, 0, "Add SA", sa->text_said);
>>> +    if (ret == FALSE && errno == ESRCH && req.n.nlmsg_type == 
>>> XFRM_MSG_UPDSA)
>>> +        return netlink_add_sa(sa, 0);
>>> 
>>> -    return send_netlink_msg(&req.n, NULL, 0, "Add SA", sa->text_said);
>>> +    return ret;
>>> }
>>> 
>>> /** netlink_del_sa - Delete an SA from the Kernel
>>> 
>>> _______________________________________________
>>> Swan mailing list
>>> Swan at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan
>>> 
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>


More information about the Swan mailing list