On Thu, Oct 05, 2006 at 09:59:27PM +0200, Sven Ulland wrote:
> Sven Ingebrigt Ulland wrote:
> >[...]
>
> Thanks to all of you who have contributed with your
> experiences with isakmpd/ipsec in OpenBSD. After some time
> now, I've seen some more of the good and bad sides of our
> VPN setup, and I'll share it with you.
>
> >How long have you been running openbsd isakmpd/ipsec (in production)?
>
> It's been running for over a year now, and it's been very
> stable.
>
> >What problems, if any, have you had with the openbsd vpn
> >implementations? Which of them are the most recurring? How do you
> >usually fix them?
>
> There are a few issues that I've seen with the
> implementation, or more aptly, my lack of detailed knowledge
> of the IPSec specs:
>
> 1) isakmpd isn't easily debuggable. When some error occurs,
> or when something expected does not occur, it is hard to
> know what debug level to increase in isakmpd. Of course, it
> would help a great deal to have detailed knowledge of the
> IPSec specs here, but I haven't found the time to get to
> know them very well. In that respect, I find the man page
> for isakmpd to be somewhat lacking.
>
> Not knowing how to debug properly leads to problems
> determining on which side the error is located, or if the
> fault is in an intermediate network. This can lead to a
> blame game with the other side, which doesn't do anyone much
> good. About that, I'm interested in hearing of good tips on
> debugging stuff like this. I use the normal tools like ping,
> {tcp,udp,icmp} traceroute, hping, tcpdump filtering on udp
> port 500 || proto 50 and isakmpd logging, but still fall
> short of determining the exact cause most of the time. Maybe
> I'm using the tools the wrong way.
>
> 2) A common problem is that we simply stop seeing data from
> one or more peers. (Our endpoint is set up as a slave for
> all the connections, so it is our peers that initiate
> connections.) What we usually do then, is to dump packets on
> the network interface to determine whether the peer is
> completely dead or if it's hung.
>
> 3) On some occations, the peer is hung up somehow, and keeps
> trying to send us an invalid SPI. Our IPSec rejects those,
> but it keeps sending them. What we then do is to stop
> isakmpd and then start it again. For some reason, this fixes
> the problem. We haven't dumped the traffic while restarting
> isakmpd yet, but it probably sends some seize and desist
> signal to all the peers. I'm wondering if it's possible to
> send this signal to just one peer.. that would keep the
> other tunnels alive.
>
> >Have you experienced any interoperability problems when establishing
> >tunnels with peers that run other implementations (cisco, checkpoint,
> >etc)? And if so, how do you work around those?
>
> Our peers mostly run cisco or checkpoint equipment. In the
> isakmpd logs we see a *lot* of the following messages:
>
> "dropped message from 172.29.9.43 port 500 due to notification type
> PAYLOAD_MALFORMED"
>
> "dropped message from 172.29.9.43 port 500 due to notification type
> INVALID_PAYLOAD_TYPE"
>
> "message_parse_payloads: invalid next payload type <Unknown 111> in payload
> of type 8"
> (the number 111 varies from ~25 to ~125)
>
> "message_parse_payloads: reserved field non-zero: 17"
> (the number varies from 0x00 to 0xff).
>
> Having a look through the IPSec specs (33 RFCs! Damn, where
> to start?) would probably explain some of this behaviour.
> I'm guessing the proprietary boxes use some in-house
> extensions. Tips are greatly welcome!
I found the references to the isakmpd.fifo mentioned in
/usr/src/sbin/isakmpd/DESIGN-NOTES useful for tearing down
specific tunnels. The part I found useful was about 57% through
the file under "User control".
Hope this helps with your situation.
