Debugging and Troubleshooting

Rekey Problems (After an Hour)

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.

Openswan Error Messages

People using Openswan for the first time find it very hard to read the error messages provided, which are rather technical in their description of the problem. People are quick to try to solve this by getting more debugging information using the plutodebug= and klipsdebug= flags, but this is not necessary and in fact, often makes things much harder for the user, as well as helpful people on the mailing list, if your message is not rejected by the mailing list for being too big to begin with.

Even in the standard configuration without any debugging enabled, Openswan logs all the information needed to debug a configuration issue. Just make sure to look at the proper log files. Usually, the startup and shutdown messages go in the general log file (often /var/log/messages), while most other log entries go to a different log file for somewhat more serious errors (usually

/var/log/secure or /var/log/auth.log).

Do not enable klipsdebug= or plutodebug= until you are pretty sure your problem is not a configuration error but a software bug.

These debug options are for developers, or for when developers ask you for logs with debugging enabled. They are only meant to help find software errors and debug protocol issues. If you enable all this debugging on a busy production server, you will likely bring the machine down by overloading its CPU and I/O disk bandwidth. If this is a remote machine and you were using SSH, you now have two problems.

IKE: Unknown VendorIDs

If you see unknown VendorIDs, it is likely that the other IPsec endpoint is requesting or notifying something unknown to Openswan. Usually VendorIDs are MD5 hashes of some option, for example:

268