oscserv error: "could not determine the owner of received UDP packet"

[Nikos Mavrogiannopoulos]

On Sat, 2014-11-15 at 13:39 +0000, David Woodhouse wrote:
> On Sat, 2014-11-15 at 12:26 +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > clients behind these nat types will have no issue as long as the nat
> > keeps the UDP association. If it is lost there is nothing in the
> > received packets that could allow ocserv to reassociate the session
> > with the correct server.
> 
> Er, don't they have the session-id in the ClientHello? And the server
> *provides* the session-id, so it could make it something which helps
> with finding the correct server.

That only works if the client detects the lost packets and restarts the
DTLS session.

> On Sat, 2014-11-15 at 12:45 +0100, Nikos Mavrogiannopoulos wrote:
> > David could openconnect reconnect the TLS channel only but continue 
> > sending on the old DTLS channel? That is what is seems to be happening
> > here.
> 
> Yes. See your own commit
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/14d807f5
> 
> It'll automatically reconnect DTLS after any CSTP reconnect, but *only*
> if DTLS doesn't have its own rehandshake timer/mechanism set up.

Correct. That seems to be an issue of semantic difference in ocserv and
anyconnect servers. ocserv gives a new DTLS session ID on every
reconnection and requires DTLS to reconnect too. That can detected by
openconnect by checking the session ID for match.

An untested patch for openconnect follows. Would that Ismail fix the
issue you notice?

> And that's probably the right thing to do. If there's been packet loss
> and the TCP connection is stalled, DTLS could be running just fine and
> the user might not even have *noticed*. We can reconnect the CSTP
> without even a momentary blip in actual *traffic* over DTLS.
> If the CSTP gives us a new session-id, though, we probably *should*
> reconnect DTLS. I think we're careful not to change our
> DTLS-Master-Secret on reconnect, aren't we?

Indeed. However, the keys being the same wouldn't help ocserv, as a DTLS
handshake has to be performed anyway. As it is the DTLS packets move to
a black hole with ocserv (on every TLS connection you get a different
DTLS session).

As I understand that case can be triggered by a random failure in the
TLS channel (e.g., cstp_write failed because the TCP session was reset),
or by setting "rekey-method = new-tunnel" in ocserv.

(in an unrelated issue for some reason DPD detection here didn't work
for DTLS which didn't try to reconnect - I don't know if Ismail has the
output of openconnect)

regards,
Nikos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-force-DTLS-reconnect-if-the-session-ID-we-get-from-T.patch
Type: text/x-patch
Size: 2175 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141115/f5eaa27e/attachment.bin>