Pulse support

David Woodhouse dwmw2 at infradead.org
Wed Oct 12 01:59:56 PDT 2016

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.

-------------- 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>

More information about the openconnect-devel mailing list