siddhesh divekar | 2 Jul 16:50 2007
Picon

[Openswan dev] integrating openswan with OCF

Hi,
    I am trying to integrate openswan with OCF. CAn any suggest me from where should I start or direct me some tutorial links.

--
Thank You,
Siddhesh M. Divekar.

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev
Michael Richardson | 2 Jul 22:39 2007

Re: [Openswan dev] integrating openswan with OCF


>>>>> "siddhesh" == siddhesh divekar <siddhesh.divekar <at> gmail.com> writes:
    siddhesh> Hi, I am trying to integrate openswan with OCF. CAn any
    siddhesh> suggest me from where should I start or direct me some
    siddhesh> tutorial links.

  I'm not really sure what you are trying to do.
  Openswan 3.xx, available from
	   http://www.openswan.org/download/development/  
  already has OCF integrated.  It is considered alpha code.

  If you are trying to add a new hardware driver to OCF, that's a
different story.

--

-- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

mds | 5 Jul 11:07 2007
Picon

[Openswan dev] pfkey_sock in spi.c

Hello!
In spi.c on line 1191 (in the main function) the following socket is 
created:
pfkey_sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2)

later in the main function a write to the socket is performed (line 1608):
write(pfkey_sock, pfkey_msg, pfkey_msg->sadb_msg_len * IPSEC_PFKEYv2_ALIGN)

I couldn't locate the code where the message that was sent by this command
is recieved.
I would apreciate a short explanation of this mechanism very much.

Thanks for your time.
   Marco

PS:
I found a file documenting what files end up in kernel & user space in
openswanDir/linux/README.openswan-2. The problem there was that
that file is outdated (last update in 2003). The ipsec_netlink.c file is 
listed
in that readme - as an example - but ipsec_netlink.c does not exist in the
current version of Openswan.
Is it alright to assume that only code located in ./linux/net end up in
kernel space? 
Michael Richardson | 6 Jul 14:56 2007

Re: [Openswan dev] DPD issue with multiple tunnels between two peers


>>>>> "Mark-Andre" == Mark-Andre Hopf <mhopf <at> innominate.com> writes:

    Mark-Andre> Was the 'restart_by_peer' option problemtatic or
    Mark-Andre> developing a fix? I see 

  I don't know what a "restart_by_peer" option is.

--

-- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Mark-Andre Hopf | 6 Jul 15:17 2007

Re: [Openswan dev] DPD issue with multiple tunnels between two peers

On Fri 06.07. 08:56, Michael Richardson wrote:

>     Mark-Andre> Was the 'restart_by_peer' option problemtatic or
>     Mark-Andre> developing a fix? I see 
>  
>   I don't know what a "restart_by_peer" option is.

Oh, sorry. I just saw that 'restart_by_peer' was part of the OCF patch

  ocf-openswan-v245rc6-20060331.diff

(What had a feature like that to do in the OCF patch...?)

 It causes Openswan do restart all connections to the same peer in case
DPD becomes active. Without it, only the connection owning the active
ISAKMP SA is restarted while the others remain dead until the keys
expire.

Mark

--

-- 
mark-andre.hopf <at> innominate.com
senior software engineer           innominate security technologies AG
development                             protecting industrial networks
tel: +49.30.6392-3284  fax: -3307                http://innominate.com
Go out and tell a lie that will make the whole family proud of you.
		-- Cadmus, to Pentheus, in "The Bacchae" by Euripides
David McCullough | 9 Jul 04:45 2007

Re: [Openswan dev] DPD issue with multiple tunnels between two peers


Jivin Mark-Andre Hopf lays it down ...
> On Fri 06.07. 08:56, Michael Richardson wrote:
> 
> >     Mark-Andre> Was the 'restart_by_peer' option problemtatic or
> >     Mark-Andre> developing a fix? I see 
> >  
> >   I don't know what a "restart_by_peer" option is.
> 
> Oh, sorry. I just saw that 'restart_by_peer' was part of the OCF patch
> 
>   ocf-openswan-v245rc6-20060331.diff
> 
> (What had a feature like that to do in the OCF patch...?)

Nothing really,  just that we added the restart_by_peer option to
openswan,  and it got bundled up with the OCF work we did as well.

>  It causes Openswan do restart all connections to the same peer in case
> DPD becomes active. Without it, only the connection owning the active
> ISAKMP SA is restarted while the others remain dead until the keys
> expire.

I wasn't involved in the reasoning behind it's addition,  so I am not
an authority on it,  nor do I have an opinion on whether or not it's a
good idea :-)

Basically this has been carried across from the freeswan code that we
deploy on our VPN products.  This functionality was deemed important
enough that it would also be needed under Openswan.  We have been
using it for a long time.

I believe the changes are tied into the dynamic DNS changes that are
also part of the patch.  I can dig up more info if anyone is interested.

Cheers,
Davidm

--

-- 
David McCullough,  david_mccullough <at> securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com
Benny Amorsen | 9 Jul 10:10 2007
Picon

Re: [Openswan dev] DPD issue with multiple tunnels between two peers

>>>>> "DM" == David McCullough <David_Mccullough <at> securecomputing.com> writes:

DM> Nothing really, just that we added the restart_by_peer option to
DM> openswan, and it got bundled up with the OCF work we did as well.

Which openswan releases have the restart_by_peer option? It seems to
me that restart_by_peer is the right thing to do in all cases, so that
dpdaction=restart should go away (or just be translated to
restart_by_peer)

/Benny
Michael Richardson | 9 Jul 17:44 2007

Re: [Openswan dev] DPD issue with multiple tunnels between two peers


>>>>> "Mark-Andre" == Mark-Andre Hopf <mhopf <at> innominate.com> writes:
    Mark-Andre> On Fri 06.07. 08:56, Michael Richardson wrote:

    Mark-Andre> Was the 'restart_by_peer' option problemtatic or
    Mark-Andre> developing a fix? I see
    >> I don't know what a "restart_by_peer" option is.

    Mark-Andre> Oh, sorry. I just saw that 'restart_by_peer' was part of
    Mark-Andre> the OCF patch

    Mark-Andre>   ocf-openswan-v245rc6-20060331.diff

    Mark-Andre> (What had a feature like that to do in the OCF
    Mark-Andre> patch...?)

  I have no idea. We didn't merge that file.

    Mark-Andre>  It causes Openswan do restart all connections to the
    Mark-Andre> same peer in case DPD becomes active. Without it, only
    Mark-Andre> the connection owning the active ISAKMP SA is restarted
    Mark-Andre> while the others remain dead until the keys expire.

  2.5.0 has the same functionality.  It does DPD on the phase 1, not the
phase 2, performing whatever actions are necessary on all phase 2s.

--

-- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Michael Richardson | 9 Jul 17:45 2007

Re: [Openswan dev] DPD issue with multiple tunnels between two peers


>>>>> "Benny" == Benny Amorsen <benny+usenet <at> amorsen.dk> writes:
    DM> Nothing really, just that we added the restart_by_peer option to
    DM> openswan, and it got bundled up with the OCF work we did as
    DM> well.

    Benny> Which openswan releases have the restart_by_peer option? It
    Benny> seems to me that restart_by_peer is the right thing to do in
    Benny> all cases, so that dpdaction=restart should go away (or just
    Benny> be translated to restart_by_peer)

  Restarting is not the right action all the time.
  Sometimes, having the conn disappear is the right action.

--

-- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

  
Venkat Yekkirala | 9 Jul 18:15 2007

Re: [Openswan dev] DPD issue with multiple tunnels between two pe ers

>     Mark-Andre>  It causes Openswan do restart all connections to the
>     Mark-Andre> same peer in case DPD becomes active. Without it, only
>     Mark-Andre> the connection owning the active ISAKMP SA is 
> restarted
>     Mark-Andre> while the others remain dead until the keys expire.
> 
>   2.5.0 has the same functionality.  It does DPD on the phase 
> 1, not the
> phase 2, performing whatever actions are necessary on all phase 2s.

But seems like only on all phase 2s for the connection owning the
phase 1 in question. Any phase 2s belonging to other connections
to the same peer (with the phase 1 SA not being around) could be
left lying around until they expire.

I am running into a similar problem, but with the DPD action set
to "clear". When a peer goes down unexpectedly, DPD on the phase 1
and RELATED phase 2s get cleared fine, but I still have other phase 2s
belonging to a different connection to the same peer lying around
without a phase 1, resulting in the follwing:

Jul  3 15:27:27 DC1 pluto[5317]: "tc-to-dc"[46] 10.1.20.119 #553: DPD:
Serious: could not find newest phase 1 state

I am a newbie to openswan and I have the following questions in this
regard:

1. Openswan seems to be negotiating a Phase 1 each for each connection
   even when the connections are all to the same peer. Is this the
   expected behaviour?

2. I seem to notice that one of the 2 phase 1s to the same peer is deleted
   after some time, causing the remaining phase 1 to be used to negotiate
   phase 2s for either connection. Is this the expected behaviour as well?

Thanks,

venkat

Gmane