On Sat, 2014-11-15 at 13:15 +0200, ?smail D?nmez wrote: > On Sat, Nov 15, 2014 at 12:04 PM, David Woodhouse <dwmw2 at infradead.org> wrote: > > > >> So the issue is to figure who is sending the UDP packets without an > >> associated TCP session. > > > > > > If a client is afflicted by NAT, especially CG-NAT, it's possible that > > separate connections may appear to come from *different* IP addresses. > > Some NAT setups have a *pool* of public-facing addresses. > > Indeed I am behind a NAT which I don't know the exact setup (This is > @work). So I guess thats the problem since I run one openconnect > client at a time. The log is a bit strange to justify a nat issue. 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. Nov 13 09:04:00 i10z ocserv[697]: worker: 212.156.31.134:42709 TLS handshake completed Nov 13 09:04:04 i10z ocserv[54495]: main: new DTLS session from 212.156.31.134:22839 (record v254.255, hello v1.0) Nov 13 09:04:04 i10z ocserv[697]: worker: 212.156.31.134:42709[ismail] DTLS handshake completed (the TLS and DTLS channels are established) Nov 13 09:18:44 i10z ocserv[54495]: main: 212.156.31.134:42709[ismail] main-misc.c:425: command socket closed Nov 13 09:18:44 i10z ocserv[54495]: main: 212.156.31.134:42709[ismail] removing client 'ismail' with id '697' (old session was discarded - the old TLS channel was terminated) Nov 13 09:18:44 i10z ocserv[1164]: worker: 212.156.31.134:35277 TLS handshake completed (a new TLS channel is established) Nov 13 09:04:04 i10z ocserv[54495]: main: new DTLS session from 212.156.31.134:22839 (record v254.255, hello v1.0) Nov 13 09:18:48 i10z ocserv[54495]: main: 212.156.31.134:22839: unexpected DTLS content type: 23; a firewall disassociated a UDP session (the DTLS channel didn't restart even though the keys have changed. The port of the received packets is suspiciously the same) regards, Nikos
