On Tue, 2016-10-11 at 17:47 -0700, Jeff Gustafson wrote: > I've been messing around with the client today and I think I screwed up > the ping. The ping *does* die when I don't put the '--no-dtls'. So > ignore that part. It was my mistake.? OK. And separately you've indicated that it wasn't related to NAT mappings timing out either ? it happens even when the link is constantly in use, and when you connect from a real IP address. > I've been trying the openconnect release in Fedora 24 and I also > compiled openconnect from git. > > The issue seems to be that --no-dtls is required for the connection to > continue to work. Without the --no-dtls, the VPN works for a minute or > so and then traffic stops coming back.? > > Is this a bug or something I should expect when using openconnect with > some combinations of VPN servers? If this isn't a completely insane setup on your side, and Juniper's own client works, then I declare it a bug. You also said when it stops working, you see it saying 'Send ESP probes'. That's odd... that's what it does when it's trying to *establish* an ESP connection. (ESP is what the Juniper protocol uses over UDP, instead of DTLS). Has it already managed to establish ESP, and then it broke down and it's trying to re-establish it? In which case, perhaps we have a bug in the code which tells the server (over the TCP channel) to switch back to sending data over TCP? Or has it never established the ESP connection at all and this is the *first* attempt? In which case... wtf. Can you show the full output with -vv? Elide passwords and cookies from it, and perhaps send it only to me. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161012/257eb0df/attachment.bin>
