Thanks for the info! I don't know much about the setkey program, so I just told what the other IT support side said to me :-)
It's correct that the ipsec auto --status shows the current keys, and all is correct in here.
The citation you've sent is however very interesting. I'm currently trying it out changing the rekeymargin and rekeyfuzz, to make sure it's our side that renegotiates each time. We'll see what it will do.
Thanks a lot!
2007/5/24, Serge Leschinsky <firstname.lastname@example.org>:
Michiel Peene wrote:
> Is there a build 1.3 available yet? can't seem to find it on the website?
1.3 is still beta (or even alpha).
> Problem we have with current version of OpenSwan is that the Tunnel
> works fine, until a new IKE key is renegotiated, then it apparently
> times out, unless we delete the IKE key on the other side of the tunnel
> (Checkpoint FW1). It worked fine for over 3 years, but since 3 months we
> have this problem.
> IT Support from the other side of the tunnel said I need to use setkey
> -D to delete the IKE key on our side and to see what happens then, but
> I don't find a way to do this with the current openswan debugging tools.
I'm not sure I understood you correct....
man 8 setkey
-D Dump the SAD entries. If -P is also specified, the SPD entries are
dumped. If -p is specified, the ports are displayed.
I may be wrong, but 'ipsec auto --status' should show the same to 'setkey -D'.
I guess this citation may be useful for you as well.
A more subtle type of error is one where initially things seem to work but after
a while the system goes down. Which endpoint is responding and which is
initiating is clear when you start the connection, but the responding end might
just start the next rekey a little bit before the initiator, and thus become the
initiator itself. You can try and trigger these kind of errors by setting the
ikelifetime=, rekeyfuzz=, and lifetime= options to very short periods of time,
such as one minute, and waiting for a few rekeys to occur.
If you have determined that the switching of initiator and responder at rekey
time is the problem, you can resolve this by lowering the IKE and IPsec key
lifetimes on the initiator end, ensuring that the initiator stays the initiator.
See the man page of ipsec.conf for help on the options lifetime=, ipseclifetime=
and rekeyfuzz=. If you are the responder, and do not control the initiator, you
can also set rekey=no to prevent becoming an initiator. After changing these
parameters to fix these issues in the future, you will need to reload the
currently stuck connection. If you want to be the responder, a simple
ipsec auto –replace connname
will do. If you want to set yourself as the initiator, you will also need to
ipsec auto –up connname the connection.
PS. I'm sure ipsec folks (openswan mail list) can help you more professionally .
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Devil-linux-discuss mailing list