[strongSwan] updown - server which disconnects one roadworrior when another connects

[Noel Kuntze]

Hi,

> Is that behavior controllable somehow, configured somewhere
> - would you know?
> Or it's the user/admin which must take care of this
> 'issue/phenomena' via the 'updown' script and the script alone?

Not controllable, you need to deal with it in the script.

Kind regards

Noel

Am 28.09.20 um 11:35 schrieb lejeczek:
> 
> 
> On 28/09/2020 10:05, Noel Kuntze wrote:
>> Hi,
>>
>> up-client is called for each combination of remote ts and local ts components, as is down-client, when a CHILD_sa is established/destroyed.
>> So when a CHILD_SA is rekeyed, both are called in the order the CHILD_SAs are negotiated/destroyed.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 28.09.20 um 10:58 schrieb lejeczek:
>>> Hi guys.
>>>
>>> I have a strongswan with 'updown' which controls tunnels,
>>> routes, etc. I took the script from doc examples and built
>>> upon it.
>>> What is perplexing totally to me is, that the scripts shows
>>> that when one roadwarrior is connected and another one is
>>> connecting then the server invokes 'down-client' which then
>>> removes - as the updown dictates - tunnel of already
>>> connected roadwarrior.
>>> Here is a snippet of the log from 'updown' script, a moment
>>> when new roadwarrior connects:
>>> ...
>>> ----RUN
>>> vti113 - down-client
>>> Mon Sep 28 09:47:20 BST 2020
>>> ip tunnel del vti113
>>> ip route del 10.3.1.12/32 dev vti113
>>>
>>> ----RUN
>>> vti114 - up-client
>>> Mon Sep 28 09:47:21 BST 2020
>>> ip tunnel add vti114 local X.X.X.X remote Z.Z.Z.Z mode vti
>>> key 11
>>> ip link set vti114 mtu 1400 up
>>> ...
>>>
>>> 'updown' script has nothing to do with that, right?
>>> Why would server do that 'down-client'?
>>>
>>> many thanks, L.
>>>
> Thanks man for explaining that.
> Is that behavior controllable somehow, configured somewhere
> - would you know?
> Or it's the user/admin which must take care of this
> 'issue/phenomena' via the 'updown' script and the script alone?
> 
> many thanks, L.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200928/7dcd748c/attachment.sig>