Recently a Kerio Connect customer needed an IPsec VPN tunnel between his office and a Cisco router at a company they had just purchased. That's easy to do: the two sides agree on a pre-shared key and unique identifiers. We also need to tell Kerio about the remote network(s) and we're done.
That VPN worked immediately and kept working for an entire two days before it failed.
Of course I asked if anything had been changed at either end and was assured that absolutely nothing had been touched. Nobody even looked at either of the routers crosseyed or had spoken harsh words in their vicinity. It was therefore, plainly, Kerio's fault (because Cisco NEVER does anything wrong, of course).
Sigh. I turned on IPsec debugging in the Debug log, but all I could really determine was that the Cisco didn't want to talk to the Kerio any longer. That wasn't helpful, so I opened a ticket with Kerio asking if there was any more I could check.
Shortly after submitting that ticket the folks at the Cisco router said, gosh, we're sorry, but something did change and they put it right. The connection came up and all was happy again.
I did get an answer from Kerio, though. They said that I could ssh to the Control command line and try this:
To increase IPsec/Charon output: ipsec stroke loglevel chd 3 For detailed debugging of cipher suites: ipsec stroke loglevel cfg 2
I don't need that now, but who knows, it may come in handy later. It's also likely that some or all of the information at IKE daemon Logger configuration would apply.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2015-12-01 Anthony Lawrence
Linux source code is freely and easily available to all of us. Understanding it is much harder. (Tony Lawrence)