[strongSwan] Strongswan 4.5.1 with sqlite database: update database and DPD

CETIAD - Fabrice Barconnière fabrice.barconniere at ac-dijon.fr
Fri Mar 4 08:43:12 CET 2011



Le 04/03/2011 07:41, Andreas Steffen a écrit :
> On 03.03.2011 17:35, Andreas Steffen wrote:
>> On 03/03/2011 10:55 AM, CETIAD - Fabrice Barconnière wrote:
>>> Hello Andreas,
>>>
>>> Thank you very much for the patch.
>>>
>>> Our ARV tool generate the same child_configs's name for each peer_configs.
>>> I think we must modify it if we want to execute "ipsec up child_name".
>>> Do you think so ?
>>>
>> Would it help you if you could start up the peer config and all attached
>> child configs would be started automatically, i.e. in our example
>> scenario
>>
>>    ipsec up net-net
>>
>> would start net-1, net-2, and net-3. This would happen only in the case
>> when there is no child config having the same name as the peer config.
>>
> I implemented this behaviour with the following patch
> http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=25ed5672a60781e9bf82efbacba4804994bd129b
>
Thank you again. I think this wil be very usefull.
>>> If we want connections to be up automatically after a restart or reboot,
>>> is there any contraindication to set start_action = 2 on each gateway or
>>> is it better to keep start_action=0 on one gateway and start_action=2 on
>>> the others and execute "ipsec up child_name/peer_name" command on either
>>> sphynx (start_action=0) or amon (start_action=2) gateway?
>>>
>> In the past usually two IKE_SAs and corresponding CHILD_SAs were
>> established and maintained over all subsequent rekeyings. This is
>> not harmful per se but creates twice the number of tunnels. I have
>> to check if the the INITIAL_CONTACT notification introduced with
>> strongSwan 4.5.1 has changed this behaviour.
>>
> This is indeed the case. With 4.5.1 you get:
>
> Mar  3 22:13:18 moon charon:
>   03[IKE] deleting duplicate IKE_SA for peer 'sun.strongswan.org' due to
> uniqueness policy
> 03[IKE] deleting IKE_SA net-net[1] between
> 192.168.0.1[moon.strongswan.org]...192.168.0.2[sun.strongswan.org]
>
So it's better to keep 0 on one side and 2 on the other and execute when 
restart ipsec or reboot "ipsec up" for each peer_configs on the gateway 
where start_action=0.

>>> In /usr/sbin/ipsec script, line 278, /var/lock/subsys/ipsec file is
>>> created if /var/lock/subsys directory exists.
>>> If subsys directory doesn't exist, ipsec file is not created. Is it
>>> normal behaviour ?
>>>
>> I even didn't know that this statement was present in the ipsec script.
>> Probably has been there since the early FreeS/WAN times. So just forget
>> about it.
>>
We test if this file is present in other scripts.
I think we can test other files as /var/run/starter.pid or/and 
/var/run/charon.pid.
>>> In strongswan.conf file, we set log as following :
>>> charon {
>>>      ..............
>>>      filelog {
>>>          /var/log/charon.log {
>>>              time_format = %b %e %T
>>>              append = yes
>>>              default = 1
>>>         }
>>>      ..............
>>>      }
>>>
>>> Logrotate archives charon.log to charon.log.x.gz.
>>> How charon daemon can create and use a new charon.log file without
>>> restarting ipsec ?
>>>
>> Hmmm, rotation of log files doesn't seem to be supported. Only if you
>> use the syslogger.
>>
OK, we will use syslogger.
>>> Best regards
>>>
>>> Fabrice
>>>
>> Kind regards
>>
>> Andreas
> Regards
>
> Andreas
>
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution!                www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>

Thanks

Fabrice




More information about the Users mailing list