https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289303
--- Comment #13 from Gert Doering <[email protected]> --- (In reply to Kristof Provost from comment #10) Well, if the kernel floats, and userland is not aware, the next TLS renegotiation (or "anything control channel") will be sent to/from the wrong peer IP, causing problems later on. But even if we were to accept this, it would still not work as-is - the current userspace logic is "if there is a notification we do not understand, close the peer instance" (comment #1). *That* seems to create more confusion later on ("Failed to create new peer: File exists"), which looks like the kernel still thinks the peer exists while userland thinks it doesn't, and then there is a duplicate endpoint. Anyway, I'll see that I can fix this for 2.6 - and maybe I can also come up with a better understanding why the server is aborting on the 3rd reconnect. What is interesting from comment #6 is that this is a "flip-flop" floating - same source IP, port A -> port B, and then port B -> back to port A. This is something which is prone to "interesting things" if the first float is not processed, and then the float "back" causes a collision (... we had SIGSEGV crashes on Linux in that situation). This is fairly easily tested by having a laptop on wifi and LAN, and plug/unplug the LAN cable repeatedly while openvpn is active and a ping is running... -- You are receiving this mail because: You are the assignee for the bug.
