John Denker | 1 Oct 2008 09:36
Favicon

[Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

Hi Folks --

I recently brought up IPsec over IPv6.  I'm happy to report
it was mostly uneventful.

For me, this is important.  It means I don't need to fool
with NAPT traversal ever again.

Of course this is using pluto with kernel IPsec via netkey, 
not using klips.

For the next level of detail on all of this, see
  http://www.av8n.com/computer/htm/ipv6-howto.htm
especially
  http://www.av8n.com/computer/htm/ipv6-howto.htm#sec-ipsec

Some suggestions:

1) There ought to be more documentation about using kernel
 IPsec instead of klips.  The documentation is very sketchy
 on this topic, and soon degenerates into unhelpful whining 
 about ancient political issues.  Also this part of the
 documentation contains some broken links.

2) Similarly, there ought to be more documentation of using
 openswan over IPv6.  I talked to some people who weren't
 even sure it would work.  There is not a single mention of 
 "connaddrfamily" in the /doc directory, unless my grep is 
 missing something (although it is mentioned properly on 
 the ipsec.conf manpage).  Some examples would be nice.
(Continue reading)

Paul Wouters | 1 Oct 2008 17:42
Gravatar

Re: [Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

On Wed, 1 Oct 2008, John Denker wrote:

Hi John,

> I recently brought up IPsec over IPv6.  I'm happy to report
> it was mostly uneventful.

Good to hear.

> 1) There ought to be more documentation about using kernel
> IPsec instead of klips.  The documentation is very sketchy
> on this topic, and soon degenerates into unhelpful whining
> about ancient political issues.  Also this part of the
> documentation contains some broken links.

There is currently only one basic test for ipv6 located at
testing/pluto/ipv6-basic-pluto-01. I would love to see more
test scenarios there.

> 2) Similarly, there ought to be more documentation of using
> openswan over IPv6.  I talked to some people who weren't
> even sure it would work.  There is not a single mention of
> "connaddrfamily" in the /doc directory, unless my grep is
> missing something (although it is mentioned properly on
> the ipsec.conf manpage).  Some examples would be nice.

Since you have just done this, how about doing an example
config to be installed in /etc/ipsec.d/examples and perhaps
a README.IPv6 with your findings and issues to date?

(Continue reading)

Anthony Tong | 1 Oct 2008 18:32

Re: [Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

John Denker wrote:
  > 3) When using kernel IPsec, it is allowable and often
>  advantageous to specify "interfaces=%none".  This ought
>  to be prominently documented somewhere.  And if you ask
>  me, it ought to be the default when using kernel IPsec.
>  And connections ought to be routed using the actual route,
>  not the "defaultroute".  This is easy to do using 
>  "ip route get to ....".  I have scripts that do this, but
>  it ought to become the standard built-in behavior.

I have modifications too for 2.4.x to handle the ipv6 routes, but
there is an issue with route cleanups that I havent had time
to look at closely and I am not even sure whether openswan is the 
culprit. os is rhel5.

When openswan shuts down and runs its corresponding route deletes
some ipv6 routes dont go away. The ip -6 route del work fine but I think 
something bumped the refcount on the route (and it wasnt from the 
openswan helper script changes) so it takes an extra delete to get rid 
of it.

I know this is kinda vague and on older software revisions, it's been a 
while. Out of curiosity, have you looked at your ip -6 route after a 
openswan shutdown.. anything odd?
John Denker | 1 Oct 2008 18:50
Favicon

Re: [Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

On 10/01/2008 08:42 AM, Paul Wouters wrote:

> Since you have just done this, how about doing an example
> config to be installed in /etc/ipsec.d/examples and perhaps
> a README.IPv6 with your findings and issues to date?

See next paragraph:

> I would like to start a README.IPv6 based on your email and your
> weg page, if you have no objections. I'll also incorporate some
> of the information in the man page for ipsec.conf.

Yes, that sounds great.

There is an example and lots of discussion at
  http://www.av8n.com/computer/htm/ipv6-howto.htm#sec-ipsec

Can you just grab that?  

If you need more/different/better stuff, please explain
more precisely what you want.

>> 3) When using kernel IPsec, it is allowable and often
> 
> Note that "kernel IPsec" is confusing, hence our insistence
> to talk about KLIPS or NETKEY.

OK, will do.

>> advantageous to specify "interfaces=%none".  This ought
(Continue reading)

Paul Wouters | 1 Oct 2008 21:09
Gravatar

Re: [Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

On Wed, 1 Oct 2008, Anthony Tong wrote:

> I have modifications too for 2.4.x to handle the ipv6 routes, but
> there is an issue with route cleanups that I havent had time
> to look at closely and I am not even sure whether openswan is the
> culprit. os is rhel5.

Please use openswan 2.6.x when using NETKEY. There are many fixes for
dealing with the ip xfrm state/policies that are not in openswan 2.4.x.
Also, _startnetkey doesn't do any of the KLIPS related routing hacks.

Paul
Paul Wouters | 2 Oct 2008 00:38
Gravatar

Re: [Openswan dev] [Patch] error: "cannot route -- route already in use for"

On Thu, 25 Sep 2008, avesh agarwal wrote:

Hi Avesh,

Sorry for the late reply....

> host1 has two interfaces: eth0 (IP address: 10.14.0.139) and eth0:1 (virtual 
> interface with IP address 10.14.0.149)
> host2 has one interface:  eth1(with IP address 10.14.0.140)
>
> I want to establish 2 ipsec channels between these two as follows.
>
> IP addresesses are as below for each
> host1<----------------->host2
> eth0(10.14.0.139)<---------------------->eth1(10.14.0.140)
>
> eth0:1 (10.14.0.149)<------------------->eth1(10.14.0.140)

[...]

> The connection 139-140 (which is between 10.14.0.139 and 10.14.0.140) gets 
> established without any problem.
> However, when the connection 149-140 (which is between 10.14.0.149 and 
> 10.14.0.140)  is setup, it gives following error:
>
> 117 "149-140" #4: STATE_QUICK_I1: initiate
> 003 "149-140" #4: cannot route -- route already in use for "139-140"
> 032 "149-140" #4: STATE_QUICK_I1: internal error
>
> Although, I have tried ipsec setup in transport mode, i think the same 
(Continue reading)

Paul Wouters | 2 Oct 2008 00:57
Gravatar

[Openswan dev] openswan 2.6.18rc1 available


A release candidate was just made. The one important bugfix we want to put
in before a final release is the KLIPS error (Unknown socket write error 96).

But for NETKEY there should not be a difference between this prerelease
and the final openswan 2.6.18 release, unless one of you finds a regression
compared to openswan 2.6.16.

Changes follow below,

Paul
(ps. note that there is no openswan 2.6.17 release)

v2.6.18
* Fix for compiling KLIPS on RHEL/Centos 2.6.18-92.1.10.el5 [dhr/paul]
* Fix in deleting connections that might have caused some of our Delete
   Notifies to have gotten lost. Introduced in openswan 2.5.01 [paul]
* Rekey= inverted yes/no, causing rekey=no to be rekey=yes [Shingo Yamawaki]
* Some memory leaks / refcount fixes [Shingo Yamawaki]
* Removed most of #ifdef CONFIG_KLIPS_DEBUG conditionals. We now always
   compile in DEBUG support. [paul]
* No longer use the assembly version of des_encrypt (dx86unix.S). It
   is i386-i686 specific, requires framepointers and does not work with
   CONFIG_REGPARM=y, which is the unconditional default for 2.6.17+ [paul]
* Fix memory leak when we run out of descriptors [David McCullough]
* Various memory leak fixes for pluto (from #macosx) [Ilia Sotnikov]
* LEAK_DETECTIVE should report better now [Ilia Sotnikov]
* Add support for USE_DMALLOC [Ilia Sotnikov]
* Update stats to show dropped packets [David McCullough]
* Allow session migration of OCF devices [Brad Vrabete]
(Continue reading)

avesh agarwal | 2 Oct 2008 03:13
Picon
Favicon

Re: [Openswan dev] [Patch] error: "cannot route -- route already in use for"

Hi Paul,

Thanks for your reply.

Paul Wouters wrote:
> On Thu, 25 Sep 2008, avesh agarwal wrote:
>
> Hi Avesh,
>
> Sorry for the late reply....
>
>> host1 has two interfaces: eth0 (IP address: 10.14.0.139) and eth0:1 
>> (virtual interface with IP address 10.14.0.149)
>> host2 has one interface:  eth1(with IP address 10.14.0.140)
>>
>> I want to establish 2 ipsec channels between these two as follows.
>>
>> IP addresesses are as below for each
>> host1<----------------->host2
>> eth0(10.14.0.139)<---------------------->eth1(10.14.0.140)
>>
>> eth0:1 (10.14.0.149)<------------------->eth1(10.14.0.140)
>
> [...]
>
>> The connection 139-140 (which is between 10.14.0.139 and 10.14.0.140) 
>> gets established without any problem.
>> However, when the connection 149-140 (which is between 10.14.0.149 
>> and 10.14.0.140)  is setup, it gives following error:
>>
(Continue reading)

Michael H. Warfield | 2 Oct 2008 16:19

Re: [Openswan dev] openswan 2.6.18rc1 available

On Wed, 2008-10-01 at 18:57 -0400, Paul Wouters wrote:

> A release candidate was just made. The one important bugfix we want to put
> in before a final release is the KLIPS error (Unknown socket write error 96).

> But for NETKEY there should not be a difference between this prerelease
> and the final openswan 2.6.18 release, unless one of you finds a regression
> compared to openswan 2.6.16.

> Changes follow below,

> Paul
> (ps. note that there is no openswan 2.6.17 release)
> 
> v2.6.18
> * Fix for compiling KLIPS on RHEL/Centos 2.6.18-92.1.10.el5 [dhr/paul]
> * Fix in deleting connections that might have caused some of our Delete
>    Notifies to have gotten lost. Introduced in openswan 2.5.01 [paul]
> * Rekey= inverted yes/no, causing rekey=no to be rekey=yes [Shingo Yamawaki]
> * Some memory leaks / refcount fixes [Shingo Yamawaki]
> * Removed most of #ifdef CONFIG_KLIPS_DEBUG conditionals. We now always
>    compile in DEBUG support. [paul]
> * No longer use the assembly version of des_encrypt (dx86unix.S). It
>    is i386-i686 specific, requires framepointers and does not work with
>    CONFIG_REGPARM=y, which is the unconditional default for 2.6.17+ [paul]
> * Fix memory leak when we run out of descriptors [David McCullough]
> * Various memory leak fixes for pluto (from #macosx) [Ilia Sotnikov]
> * LEAK_DETECTIVE should report better now [Ilia Sotnikov]
> * Add support for USE_DMALLOC [Ilia Sotnikov]
> * Update stats to show dropped packets [David McCullough]
(Continue reading)

Knoke, Jim | 2 Oct 2008 23:14
Favicon

[Openswan dev] any plans to get FIPS certification?

For all the crypto and RNG algorithms used for IPsec? 
 
Or any other suggestions for how to get a FIPSed, open source IPsec solution going on Linux?
 
Thanks for any help. 

**********
The information contained in this communication is confidential and privileged proprietary information intended only for the personal and confidential use of the individual or entity to whom it is addressed. If you are not the addressee indicated in this message (or an agent responsible for delivery of the message to such person), you are hereby notified that you have received this communication in error and that any review, dissemination, copying or unauthorized use of this message is strictly prohibited. In such case, you should destroy this message and kindly notify the sender by email.

Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Cryptek shall be understood as neither given nor endorsed by it. It is Cryptek's policy that emails are intended for and should be used for business purposes only.
**********
_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev

Gmane