[Swan] repetitive reestablishment of ipsec

Philippe Vouters philippe.vouters at laposte.net
Fri Jan 4 18:44:04 EET 2013


Dear Nick,

Would the root cause to the problem be my change in routine 
resolve_defaultroute_one (file libreswan-3.0/programs/addconn/addconn.c)
with:
     if (has_dst == 0) {
         struct nlmsghdr *nlmsg = (struct nlmsghdr *)msgbuf;
         nlmsg->nlmsg_flags |= NLM_F_DUMP;
*        if (parse_gateway)**
***parse_src = 0;*
*    }
I have been attempting to satisfy such a connection configuration 
described at 
http://vouters.dyndns.org/tima/Linux-Libreswan-Setting_up_an_Intranet_VPN_with_Windows_7.html 
where there is no leftnexthop. In bold my change.

To make sure the problem actually comes from addconn : # ipsec addconn 
--verbose --autoall

In the hope this can help.

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 04/01/2013 17:10, Nick Howitt a écrit :
> *** Message resent - first not gone through? ***
>
> Paul,
>
> A few of us are trying to develop a front end for this/Openswan in 
> ClearOS, and one person has tried LibreSwan and he got the same thing. 
> If you look in Oguz Yilmaz's log you will see:
>
> Jan  2 10:18:28 2013 pluto[18211]: \"myvpn/0x2\" #2: route-client
> output:/usr/libexec/ipsec/_updown.netkey: doroute `ip route replace
> 192.168.2.0/24 via 10.46.1.5 dev lo  src 10.46.1.5\' failed (RTNETLINK
> answers: No such process)
>
> The tester's comment is "The only bad news is that the 
> /usr/libexec/ipsec/_updown.netkey appears to have been modified, such 
> that the local route from the gateway fails as it attempts to use the 
> 'lo' interface rather than the default route... still investigating 
> why this differs between packages"
>
> HTH,
>
> Nick
>
> On 03/01/2013 23:36, Paul Wouters wrote:
>>
>> On Fri, 4 Jan 2013, Oguz Yilmaz wrote:
>>
>>> 2 is resolved as I said. But
>>>
>>> 1- Why it takes about 2 minutes after restart of ipsec to establish 
>>> connection?
>>>
>>> continues.
>>
>> That should not be the case. If you can provide some logs that we can
>> investigate.
>>
>> Paul
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20130104/97c289fb/attachment.html>


More information about the Swan mailing list