headers
Mattias Walstrom | 4 Feb 2011 15:26
Favicon

[Openswan dev] Initiate on demand and netkey

We have had problems with initiate on demand triggering, and it often goes well but sometimes this results
in different understanding about which SPI to use for the traffic on both ends (and communication is lost).

As I had understood, intiate on demand is only useful for MAST/KLIPS, or have I missed something here?

Index: openswan-2.6.32/programs/pluto/initiate.c
===================================================================
--- openswan-2.6.32.orig/programs/pluto/initiate.c
+++ openswan-2.6.32/programs/pluto/initiate.c
 <at>  <at>  -730,6 +730,9  <at>  <at>  initiate_ondemand_body(struct find_oppo_
     /* on klips/mast assume we will do something */
     work = (kern_interface == USE_KLIPS || kern_interface == USE_MASTKLIPS);

+    if (!work)
+        return work;
+
     /* What connection shall we use?
      * First try for one that explicitly handles the clients.
      */
Permalink | Reply | 2 comments |
headers
Michael H. Warfield | 4 Feb 2011 17:03

Re: [Openswan dev] Initiate on demand and netkey

On Fri, 2011-02-04 at 15:26 +0100, Mattias Walstrom wrote:
> We have had problems with initiate on demand triggering, and it often
> goes well but sometimes this results in different understanding about
> which SPI to use for the traffic on both ends (and communication is
> lost). 
> 
> As I had understood, intiate on demand is only useful for MAST/KLIPS,
> or have I missed something here?

Why would it only be useful for MAST/KLIPS and not netkey?  Maybe I'm
missing something here.  I've never used initiate on demand under
Openswan but, a long time ago, I was playing with it under Racoon.  If
there's a problem with which SPI to use, that sounds like something that
needs to be fixed.

> Index: openswan-2.6.32/programs/pluto/initiate.c
> ===================================================================
> --- openswan-2.6.32.orig/programs/pluto/initiate.c
> +++ openswan-2.6.32/programs/pluto/initiate.c
>  <at>  <at>  -730,6 +730,9  <at>  <at>  initiate_ondemand_body(struct find_oppo_
>      /* on klips/mast assume we will do something */
>      work = (kern_interface == USE_KLIPS || kern_interface == USE_MASTKLIPS);
>  
> +    if (!work)
> +        return work;
> +
>      /* What connection shall we use?
>       * First try for one that explicitly handles the clients.
>       */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Avesh Agarwal | 4 Feb 2011 17:20
Picon
Favicon

Re: [Openswan dev] Initiate on demand and netkey

On 02/04/2011 09:26 AM, Mattias Walstrom wrote:
> We have had problems with initiate on demand triggering, and it often goes well but sometimes this results
in different understanding about which SPI to use for the traffic on both ends (and communication is lost).
>
> As I had understood, intiate on demand is only useful for MAST/KLIPS, or have I missed something here?
>
> Index: openswan-2.6.32/programs/pluto/initiate.c
> ===================================================================
> --- openswan-2.6.32.orig/programs/pluto/initiate.c
> +++ openswan-2.6.32/programs/pluto/initiate.c
>  <at>  <at>  -730,6 +730,9  <at>  <at>  initiate_ondemand_body(struct find_oppo_
>       /* on klips/mast assume we will do something */
>       work = (kern_interface == USE_KLIPS || kern_interface == USE_MASTKLIPS);
>
> +    if (!work)
> +        return work;
> +
>       /* What connection shall we use?
>        * First try for one that explicitly handles the clients.
>        */
We use initiation on demand with netkey frequently. The issue you are 
stating, needs to be fixed somewhere else.

Thanks and Regards
Avesh
> _______________________________________________
> Dev mailing list
> Dev <at> openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tuomo Soini | 5 Feb 2011 13:41
Picon
Favicon

Re: [Openswan dev] We can now remove a temoprary workaround from 2.6.24

Paul Wouters wrote:
> On Sun, 30 Jan 2011, Elio Maldonado Batiz wrote:
> 
>> The 2.6.14 release included this
>>
>> * Fix for compiling with nss and broken nspr header [Elio Maldonado Batiz]
>> The faulty header was fixed in nspr 4.8.6, see:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=410677
>>
>> That temporary workaround is no longer needed. Enclosed is a patch to
>> reenable strict prototype checking in rsasigkey and showhostkey.
> 
> Since centos6 is not yet released, and centos5 still ships nspr 4.8.4,
> I would prefer to wait a little longer.

Fully patched centos-5 system doesn't have this problem any more. nss
was patched not to include nspr.h where it wasn't needed so this issue
is gone there too. Please apply the path.

--

-- 
Tuomo Soini <tis <at> foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>
Permalink | Reply | 0 comments |
headers
Wolfgang Nothdurft | 7 Feb 2011 17:10
Picon
Favicon

[Openswan dev] why pluto adds the leftsourceip to the ipsec device?

Hi,

as I reported in https://gsoc.xelerance.com/issues/1199 there is a
problem when the netmask between the configured leftsubnet and the real
local subnet differs.

Another problem can be when doing an ifdown/up on the local interface
which is not the ipsec base interface. Then the local route is added
after the ipsec route and no access to the lan is possible.

My general question is, why there is a need to add the leftsourceip to
the ipsec device?

Are the addsource and changesource functions in the updown script
necessary nowadays, with actual systems.
The doroute function adds a route to the remote net with the
leftsourceip as src, so all traffic are getting the right sourceip or
are there some corner cases that I miss.

Regards
Wolfgang
Permalink | Reply | 6 comments |
headers
Roel van Meer | 8 Feb 2011 07:39
Picon
Favicon

Re: [Openswan dev] why pluto adds the leftsourceip to the ipsec device?

Wolfgang Nothdurft writes:

> as I reported in https://gsoc.xelerance.com/issues/1199 there is a
> problem when the netmask between the configured leftsubnet and the real
> local subnet differs.
> 
> Another problem can be when doing an ifdown/up on the local interface
> which is not the ipsec base interface. Then the local route is added
> after the ipsec route and no access to the lan is possible.
> 
> My general question is, why there is a need to add the leftsourceip to
> the ipsec device?

Since openswan 2.6.32 the leftsourceip is added with a /32 netmask, thus 
preventing any local routes to be added via the ipsec interface. This should 
fix the problem you have with losing access to your lan.

Which version is it that you are experiencing this problem with?

Regards,

Roel

> Are the addsource and changesource functions in the updown script
> necessary nowadays, with actual systems.
> The doroute function adds a route to the remote net with the
> leftsourceip as src, so all traffic are getting the right sourceip or
> are there some corner cases that I miss.
> 
> Regards
(Continue reading)

Permalink | Reply | 5 comments |
headers
Wolfgang Nothdurft | 8 Feb 2011 10:35
Picon
Favicon

Re: [Openswan dev] why pluto adds the leftsourceip to the ipsec device?

Am 08.02.2011 07:39, schrieb Roel van Meer:
> Wolfgang Nothdurft writes:
> 
>> as I reported in https://gsoc.xelerance.com/issues/1199 there is a
>> problem when the netmask between the configured leftsubnet and the real
>> local subnet differs.
>>
>> Another problem can be when doing an ifdown/up on the local interface
>> which is not the ipsec base interface. Then the local route is added
>> after the ipsec route and no access to the lan is possible.
>>
>> My general question is, why there is a need to add the leftsourceip to
>> the ipsec device?
> 
> Since openswan 2.6.32 the leftsourceip is added with a /32 netmask, thus 
> preventing any local routes to be added via the ipsec interface. This should 
> fix the problem you have with losing access to your lan.
> 
> Which version is it that you are experiencing this problem with?

I use 2.6.29 with klips and I can't see any changes in 2.6.32.

I think it is a problem with the query:

287     cidr=${PLUTO_MY_CLIENT##*/}
288     snet=${PLUTO_MY_SOURCEIP%/*}/32
289     if test "${PLUTO_PEER_CLIENT}" != "${cidr}"
290     then
291         snet=${PLUTO_MY_SOURCEIP%/*}/${cidr}
292     fi
(Continue reading)

Permalink | Reply | 4 comments |
headers
Wolfgang Nothdurft | 8 Feb 2011 10:50
Picon
Favicon

Re: [Openswan dev] [Openswan Users] XL2TP/iPhone don't work because of wrong route/ip for UDP/1701 answer packets

Am 28.01.2011 11:30, schrieb Wolfgang Nothdurft:
> Am 18.01.2011 15:52, schrieb Paul Wouters:
>> On Tue, 18 Jan 2011, Wolfgang Nothdurft wrote:
>>
>>> Now, since one or two weeks, it proposes that it is behind nat (see
>>> l2tp_iphone_new.txt), but sends the l2tp 1701/udp packets anyway with
>>> the public ip through the ipsec tunnel. Because openswan only insert a
>>> route to the proposed local ip through the tunnel the answer packets
>>> were routed direct over the default route.
>>>
>>> The l2tpd gets only the repeatedly incoming request and logs:
>>>
>>> Jan 18 11:27:44 riab l2tpd[4229]: control_finish: Peer requested tunnel
>>> 21 twice, ignoring second one.
>>
>> Ohh. I did not realise that was the actual problem in these scenarios...
>>
>>> Removing the rightsubnet parameter from the config let the iPhone
>>> connect, but than all other clients (Win7, etc) who proposes correctly
>>> are left out.
>>
>> Can you try with one conn without rightsubnet and one conn with
>> rightsubnet=vhost:%priv
>> (without the %no). I wonder if that's what is causing this?
>>
>> This might be a NAT-OA related bug on our end?
>>
>>> Does anyone else see this problem?
>>
>> Yes, we see reports of these regularly, but I hadn't realised the problem
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roel van Meer | 8 Feb 2011 10:53
Picon
Favicon

Re: [Openswan dev] why pluto adds the leftsourceip to the ipsec device?

Wolfgang Nothdurft writes:

>> Since openswan 2.6.32 the leftsourceip is added with a /32 netmask, thus 
>> preventing any local routes to be added via the ipsec interface. This should 
>> fix the problem you have with losing access to your lan.

Sorry, this was a different problem.

>> Which version is it that you are experiencing this problem with?
> 
> I use 2.6.29 with klips and I can't see any changes in 2.6.32.
> 
> I think it is a problem with the query:
> 
> 287     cidr=${PLUTO_MY_CLIENT##*/}
> 288     snet=${PLUTO_MY_SOURCEIP%/*}/32
> 289     if test "${PLUTO_PEER_CLIENT}" != "${cidr}"
> 290     then
> 291         snet=${PLUTO_MY_SOURCEIP%/*}/${cidr}
> 292     fi
> 
> 
> "${PLUTO_PEER_CLIENT}" != "${cidr}"  always differs
> 
> mustn't it be
> 
> "${PLUTO_PEER_CLIENT##*/}" != "${cidr}"
> 
> but anyway why ipsec needs this local ip on the ipsec device?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wolfgang Nothdurft | 8 Feb 2011 13:58
Picon
Favicon

Re: [Openswan dev] why pluto adds the leftsourceip to the ipsec device?

Am 08.02.2011 10:53, schrieb Roel van Meer:
> Wolfgang Nothdurft writes:
> 
>>> Since openswan 2.6.32 the leftsourceip is added with a /32 netmask,
>>> thus preventing any local routes to be added via the ipsec interface.
>>> This should fix the problem you have with losing access to your lan.
> 
> Sorry, this was a different problem.
> 
>>> Which version is it that you are experiencing this problem with?
>>
>> I use 2.6.29 with klips and I can't see any changes in 2.6.32.
>>
>> I think it is a problem with the query:
>>
>> 287     cidr=${PLUTO_MY_CLIENT##*/}
>> 288     snet=${PLUTO_MY_SOURCEIP%/*}/32
>> 289     if test "${PLUTO_PEER_CLIENT}" != "${cidr}"
>> 290     then
>> 291         snet=${PLUTO_MY_SOURCEIP%/*}/${cidr}
>> 292     fi
>>
>>
>> "${PLUTO_PEER_CLIENT}" != "${cidr}"  always differs
>>
>> mustn't it be
>>
>> "${PLUTO_PEER_CLIENT##*/}" != "${cidr}"
>>
>> but anyway why ipsec needs this local ip on the ipsec device?
(Continue reading)

Permalink | Reply | 2 comments |

Gmane