[prev in list] [next in list] [prev in thread] [next in thread]
List: strongswan-users
Subject: Re: [strongSwan] Recommended command order.
From: Ali Masoudi <masoudi1983 () gmail ! com>
Date: 2013-09-21 6:49:29
Message-ID: CAAxMqJoT-D5YTvbLVH+ARJpc_E5x8NuFB=CNLztw87JDmEn78Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi
Regarding to my experience, using `ipsec reload` is usually unnecessary.
ipsec update and ipsec reread(secrets,all,...) is adequate. Besides, "ipsec
reload" sometimes makes running tunnels duplicate.
Best regards
Ali
On Thu, Sep 19, 2013 at 10:11 PM, Tom Rymes <trymes@rymes.com> wrote:
> We currently use a firewall distro that has a GUI to
> add/modfiy/delete/restart StrongSwan tunnels. The update to v5 of
> StrongSwan caused some issues, which were eventually traced back to the
> GUI issuing "ipsec reload", but not "ipsec rereadsecrets" when creating
> a PSK tunnel.
>
> My hunch here is that this worked with StrongSwan v4 and earlier because
> pluto restarted whenever 'ipsec reload' was issued, such that the entire
> configuration, including ipsec.secrets was reloaded, even if you did not
> explicitly issue "ipsec rereadsecrets" or "ipsec rereadall". However,
> beginning with v5, charon does not do this, and as such, issuing 'ipsec
> reload' without 'rereadsecrets' causes charon to see the new tunnel, but
> not the new PSK, and as such, fail to bring the tunnel up. This hunch is
> based on the fact that the docs say 'ipsec update' and 'ipsec reload'
> only determine changes in ipsec.conf, not in any other files, such as
> ipsec.secrets
> (http://wiki.strongswan.org/projects/strongswan/wiki/IpsecCommand).
>
> In any case, that issue has been corrected in the GUI by adding 'ipsec
> rereadall' prior to issuing 'ipsec reload'. However, I am now wondering,
> what is the proper order of commands to issue once you have
> added/deleted/stopped a tunnel", such that similar situations can be
> avoided?
>
> For example: Does it also make sense to issue a rereadall command when
> deleting a tunnel, such that charon forgets the PSK and IDs?
>
> When would you issue a reload and not reread secrets/all/etc?
>
> Hopefully this isn't an overly obvious question, any thoughts appreciated.
>
> Tom
>
> _______________________________________________
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi<div><br></div><div>Regarding to my experience, using `ipsec reload` \
is usually unnecessary. ipsec update and ipsec reread(secrets,all,...) is adequate. \
Besides, "ipsec reload" sometimes makes running tunnels duplicate.</div> \
<div><br></div><div>Best regards</div><div>Ali</div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 10:11 \
PM, Tom Rymes <span dir="ltr"><<a href="mailto:trymes@rymes.com" \
target="_blank">trymes@rymes.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">We currently use a firewall distro that has a GUI to<br> \
add/modfiy/delete/restart StrongSwan tunnels. The update to v5 of<br> StrongSwan \
caused some issues, which were eventually traced back to the<br> GUI issuing \
"ipsec reload", but not "ipsec rereadsecrets" when creating<br> a \
PSK tunnel.<br> <br>
My hunch here is that this worked with StrongSwan v4 and earlier because<br>
pluto restarted whenever 'ipsec reload' was issued, such that the entire<br>
configuration, including ipsec.secrets was reloaded, even if you did not<br>
explicitly issue "ipsec rereadsecrets" or "ipsec rereadall". \
However,<br> beginning with v5, charon does not do this, and as such, issuing \
'ipsec<br> reload' without 'rereadsecrets' causes charon to see the \
new tunnel, but<br> not the new PSK, and as such, fail to bring the tunnel up. This \
hunch is<br> based on the fact that the docs say 'ipsec update' and \
'ipsec reload'<br> only determine changes in ipsec.conf, not in any other \
files, such as<br> ipsec.secrets<br>
(<a href="http://wiki.strongswan.org/projects/strongswan/wiki/IpsecCommand" \
target="_blank">http://wiki.strongswan.org/projects/strongswan/wiki/IpsecCommand</a>).<br>
<br>
In any case, that issue has been corrected in the GUI by adding 'ipsec<br>
rereadall' prior to issuing 'ipsec reload'. However, I am now \
wondering,<br> what is the proper order of commands to issue once you have<br>
added/deleted/stopped a tunnel", such that similar situations can be<br>
avoided?<br>
<br>
For example: Does it also make sense to issue a rereadall command when<br>
deleting a tunnel, such that charon forgets the PSK and IDs?<br>
<br>
When would you issue a reload and not reread secrets/all/etc?<br>
<br>
Hopefully this isn't an overly obvious question, any thoughts appreciated.<br>
<br>
Tom<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" \
target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br> \
</blockquote></div><br></div>
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic