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
>>>>> "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"); [
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?
>>>>> "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"); [
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
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 ideaBasically 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
>>>>> "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
>>>>> "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"); [
>>>>> "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"); [
> 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
RSS Feed1 | |
|---|---|
3 | |
4 | |
8 | |
3 | |
4 | |
3 | |
6 | |
8 | |
9 | |
22 | |
12 | |
9 | |
7 | |
10 | |
9 | |
8 | |
29 | |
19 | |
30 | |
11 | |
2 | |
36 | |
15 | |
81 | |
35 | |
198 | |
10 | |
32 | |
20 | |
14 | |
32 | |
39 | |
99 | |
40 | |
45 | |
13 | |
5 | |
18 | |
4 | |
17 | |
15 | |
21 | |
13 | |
10 | |
16 | |
28 | |
12 | |
24 | |
29 | |
17 | |
16 | |
11 | |
19 | |
42 | |
14 | |
5 | |
20 | |
8 | |
19 | |
60 | |
24 | |
32 | |
4 | |
8 | |
45 | |
34 | |
24 | |
17 | |
23 | |
6 | |
9 | |
20 | |
37 | |
9 | |
9 | |
18 | |
16 | |
24 | |
13 | |
34 | |
21 | |
44 | |
47 | |
38 | |
58 | |
34 | |
50 | |
70 | |
37 | |
18 | |
19 | |
65 | |
37 | |
24 | |
21 | |
45 | |
40 | |
33 | |
53 | |
65 | |
69 | |
95 | |
89 | |
57 |
