Re: Strongswan and auto=start

Re: Strongswan and auto=start

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

Hi,

I tried to change this in the CGI, but it is not so easy.

But I would be in favour of On-Demand being the default.

Best,
-Michael

> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
> 
> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
> 
> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
> 
> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
> 
> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
> 
> This raises the question as to why auto=start is still the default in IPFire.
> 
> Thoughts?
> 
> Tom

Re: Strongswan and auto=start

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

Would it not be possible to revert to the old CGI, prior to On-Demand and change the auto=start line to auto=route? We did that for years.

Tom

> On Feb 18, 2019, at 6:43 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
> 
> Hi,
> 
> I tried to change this in the CGI, but it is not so easy.
> 
> But I would be in favour of On-Demand being the default.
> 
> Best,
> -Michael
> 
>> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
>> 
>> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
>> 
>> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
>> 
>> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
>> 
>> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
>> 
>> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
>> 
>> This raises the question as to why auto=start is still the default in IPFire.
>> 
>> Thoughts?
>> 
>> Tom
> 

Re: Strongswan and auto=start

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Hi,

No, auto=start was the default.

I would prefer to have auto=route as the default.

When you say you did that for years you are referring to your own setup, right?

-Michael

> On 25 Feb 2019, at 23:16, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> Would it not be possible to revert to the old CGI, prior to On-Demand and change the auto=start line to auto=route? We did that for years.
> 
> Tom
> 
>> On Feb 18, 2019, at 6:43 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> I tried to change this in the CGI, but it is not so easy.
>> 
>> But I would be in favour of On-Demand being the default.
>> 
>> Best,
>> -Michael
>> 
>>> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
>>> 
>>> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
>>> 
>>> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
>>> 
>>> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
>>> 
>>> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
>>> 
>>> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
>>> 
>>> This raises the question as to why auto=start is still the default in IPFire.
>>> 
>>> Thoughts?
>>> 
>>> Tom
>> 
> 

Re: Strongswan and auto=start

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]

Yes, my apologies, I thought I had sent that message days ago, but it was sitting there waiting to be sent, and it clearly could have been more, um, clear.

What I meant was that, for years, we routinely modified the CGI to change the line that wrote out “auto=start” to “auto=route”. This made it so that the tunnel configurations were automatically written out correctly, and we just had to remember to modify that one line after updates when the CGI was overwritten (like we currently do for unbound and .internal domains).

Would it not be possible to revert to the old CGI, then make that one modification to have all Net-to-Net tunnels use auto=route? We could then add in a timeout function and drop down if folks would like to retain the on-demand functionality (though I think that unlimited should be the default, as I imagine most net-to-net tunnels are intended to be always-on).

Tom

> On Feb 27, 2019, at 11:47 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
> 
> Hi,
> 
> No, auto=start was the default.
> 
> I would prefer to have auto=route as the default.
> 
> When you say you did that for years you are referring to your own setup, right?
> 
> -Michael
> 
>> On 25 Feb 2019, at 23:16, Tom Rymes <trymes(a)rymes.com> wrote:
>> 
>> Would it not be possible to revert to the old CGI, prior to On-Demand and change the auto=start line to auto=route? We did that for years.
>> 
>> Tom
>> 
>>> On Feb 18, 2019, at 6:43 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I tried to change this in the CGI, but it is not so easy.
>>> 
>>> But I would be in favour of On-Demand being the default.
>>> 
>>> Best,
>>> -Michael
>>> 
>>>> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
>>>> 
>>>> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
>>>> 
>>>> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
>>>> 
>>>> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
>>>> 
>>>> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
>>>> 
>>>> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
>>>> 
>>>> This raises the question as to why auto=start is still the default in IPFire.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Tom
>>> 
>> 
> 

Re: Strongswan and auto=start

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3625 bytes --]

Hi,

I got it. Yay!

  https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=eb09c90ef47606f616201fddc5e783149aee9228

The patch looks simple, but this was a lot of work :(

And I changed the default straight away:

  https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=b15b70bc6b6b5f6d8b62e5b730b68d86f59810e6

This is what we want, isn’t it?

Best,
-Michael

> On 27 Feb 2019, at 17:12, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> Yes, my apologies, I thought I had sent that message days ago, but it was sitting there waiting to be sent, and it clearly could have been more, um, clear.
> 
> What I meant was that, for years, we routinely modified the CGI to change the line that wrote out “auto=start” to “auto=route”. This made it so that the tunnel configurations were automatically written out correctly, and we just had to remember to modify that one line after updates when the CGI was overwritten (like we currently do for unbound and .internal domains).
> 
> Would it not be possible to revert to the old CGI, then make that one modification to have all Net-to-Net tunnels use auto=route? We could then add in a timeout function and drop down if folks would like to retain the on-demand functionality (though I think that unlimited should be the default, as I imagine most net-to-net tunnels are intended to be always-on).
> 
> Tom
> 
>> On Feb 27, 2019, at 11:47 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> No, auto=start was the default.
>> 
>> I would prefer to have auto=route as the default.
>> 
>> When you say you did that for years you are referring to your own setup, right?
>> 
>> -Michael
>> 
>>> On 25 Feb 2019, at 23:16, Tom Rymes <trymes(a)rymes.com> wrote:
>>> 
>>> Would it not be possible to revert to the old CGI, prior to On-Demand and change the auto=start line to auto=route? We did that for years.
>>> 
>>> Tom
>>> 
>>>> On Feb 18, 2019, at 6:43 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I tried to change this in the CGI, but it is not so easy.
>>>> 
>>>> But I would be in favour of On-Demand being the default.
>>>> 
>>>> Best,
>>>> -Michael
>>>> 
>>>>> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
>>>>> 
>>>>> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
>>>>> 
>>>>> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
>>>>> 
>>>>> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
>>>>> 
>>>>> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
>>>>> 
>>>>> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
>>>>> 
>>>>> This raises the question as to why auto=start is still the default in IPFire.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Tom
>>>> 
>>> 
>> 

Re: Strongswan and auto=start

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]

Great news, Michael, thanks for putting the work in on this. It sure 
looks like the right solution to me.

I would suggest that we consider changing the default for 
INACTIVIY_TIMEOUT to unlimited, but I can see how others might differ on 
that.

Tom

On 03/05/2019 10:28 AM, Michael Tremer wrote:
> Hi,
> 
> I got it. Yay!
> 
>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=eb09c90ef47606f616201fddc5e783149aee9228
> 
> The patch looks simple, but this was a lot of work :(
> 
> And I changed the default straight away:
> 
>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=b15b70bc6b6b5f6d8b62e5b730b68d86f59810e6
> 
> This is what we want, isn’t it?
> 
> Best,
> -Michael
> 
>> On 27 Feb 2019, at 17:12, Tom Rymes <trymes(a)rymes.com> wrote:
>>
>> Yes, my apologies, I thought I had sent that message days ago, but it was sitting there waiting to be sent, and it clearly could have been more, um, clear.
>>
>> What I meant was that, for years, we routinely modified the CGI to change the line that wrote out “auto=start” to “auto=route”. This made it so that the tunnel configurations were automatically written out correctly, and we just had to remember to modify that one line after updates when the CGI was overwritten (like we currently do for unbound and .internal domains).
>>
>> Would it not be possible to revert to the old CGI, then make that one modification to have all Net-to-Net tunnels use auto=route? We could then add in a timeout function and drop down if folks would like to retain the on-demand functionality (though I think that unlimited should be the default, as I imagine most net-to-net tunnels are intended to be always-on).
>>
>> Tom
>>
>>> On Feb 27, 2019, at 11:47 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>>
>>> Hi,
>>>
>>> No, auto=start was the default.
>>>
>>> I would prefer to have auto=route as the default.
>>>
>>> When you say you did that for years you are referring to your own setup, right?
>>>
>>> -Michael
>>>
>>>> On 25 Feb 2019, at 23:16, Tom Rymes <trymes(a)rymes.com> wrote:
>>>>
>>>> Would it not be possible to revert to the old CGI, prior to On-Demand and change the auto=start line to auto=route? We did that for years.
>>>>
>>>> Tom
>>>>
>>>>> On Feb 18, 2019, at 6:43 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I tried to change this in the CGI, but it is not so easy.
>>>>>
>>>>> But I would be in favour of On-Demand being the default.
>>>>>
>>>>> Best,
>>>>> -Michael
>>>>>
>>>>>> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
>>>>>>
>>>>>> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
>>>>>>
>>>>>> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
>>>>>>
>>>>>> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
>>>>>>
>>>>>> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
>>>>>>
>>>>>> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
>>>>>>
>>>>>> This raises the question as to why auto=start is still the default in IPFire.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Tom
>>>>>
>>>>
>>>
> 

Re: Strongswan and auto=start

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4481 bytes --]

Hi,

Good question. It would be nice if we could have some good documentation about parameters like the inactivity timeout on the wiki.

There is no good default for that I think. I could live with unlimited. My tunnels are usually all over the place because it doesn’t matter as they all have activity all the time…

-Michael

> On 5 Mar 2019, at 16:51, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> Great news, Michael, thanks for putting the work in on this. It sure looks like the right solution to me.
> 
> I would suggest that we consider changing the default for INACTIVIY_TIMEOUT to unlimited, but I can see how others might differ on that.
> 
> Tom
> 
> On 03/05/2019 10:28 AM, Michael Tremer wrote:
>> Hi,
>> I got it. Yay!
>>   https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=eb09c90ef47606f616201fddc5e783149aee9228
>> The patch looks simple, but this was a lot of work :(
>> And I changed the default straight away:
>>   https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=b15b70bc6b6b5f6d8b62e5b730b68d86f59810e6
>> This is what we want, isn’t it?
>> Best,
>> -Michael
>>> On 27 Feb 2019, at 17:12, Tom Rymes <trymes(a)rymes.com> wrote:
>>> 
>>> Yes, my apologies, I thought I had sent that message days ago, but it was sitting there waiting to be sent, and it clearly could have been more, um, clear.
>>> 
>>> What I meant was that, for years, we routinely modified the CGI to change the line that wrote out “auto=start” to “auto=route”. This made it so that the tunnel configurations were automatically written out correctly, and we just had to remember to modify that one line after updates when the CGI was overwritten (like we currently do for unbound and .internal domains).
>>> 
>>> Would it not be possible to revert to the old CGI, then make that one modification to have all Net-to-Net tunnels use auto=route? We could then add in a timeout function and drop down if folks would like to retain the on-demand functionality (though I think that unlimited should be the default, as I imagine most net-to-net tunnels are intended to be always-on).
>>> 
>>> Tom
>>> 
>>>> On Feb 27, 2019, at 11:47 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> No, auto=start was the default.
>>>> 
>>>> I would prefer to have auto=route as the default.
>>>> 
>>>> When you say you did that for years you are referring to your own setup, right?
>>>> 
>>>> -Michael
>>>> 
>>>>> On 25 Feb 2019, at 23:16, Tom Rymes <trymes(a)rymes.com> wrote:
>>>>> 
>>>>> Would it not be possible to revert to the old CGI, prior to On-Demand and change the auto=start line to auto=route? We did that for years.
>>>>> 
>>>>> Tom
>>>>> 
>>>>>> On Feb 18, 2019, at 6:43 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I tried to change this in the CGI, but it is not so easy.
>>>>>> 
>>>>>> But I would be in favour of On-Demand being the default.
>>>>>> 
>>>>>> Best,
>>>>>> -Michael
>>>>>> 
>>>>>>> On 18 Feb 2019, at 04:44, Tom Rymes <trymes(a)rymes.com> wrote:
>>>>>>> 
>>>>>>> A while back, I made a feature request to allow configuration of the Strongswan “auto” parameter via the WUI. This made its way into the WUI as the “On-Demand” feature a while back (thank you!!!) https://bugzilla.ipfire.org/show_bug.cgi?id=10733
>>>>>>> 
>>>>>>> At the time, I had posted a few links to messages on the StrongSwan mailing list that indicated that auto=route results in superior reliability, and our experience bears this out, but the default remains “auto=start”.
>>>>>>> 
>>>>>>> In order to support Windows roadwarrior connections, IPFire’s host cert needs a dns Subject Alt Name, so I had to delete all of our tunnels and certs, then recreate them. This meant that I had to change both sides of ~20 tunnels from the default “Always On” (auto=start) to “On Demand” (auto=route).
>>>>>>> 
>>>>>>> Coincidentally, this message from one of the developers came across the StrongSwan Users list tonight, which basically makes clear that auto=start should not be used: https://lists.strongswan.org/pipermail/users/2019-February/013373.html
>>>>>>> 
>>>>>>> The relevant quotation: “Use auto=route. Auto=start is not reliable.”
>>>>>>> 
>>>>>>> This raises the question as to why auto=start is still the default in IPFire.
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> Tom
>>>>>> 
>>>>> 
>>>>