On Fri, Jul 13, 2018 at 1:40 PM, Gareth Williams <gareth at garethwilliams.me.uk> wrote: > Hi Nikos, > > Thanks for your (and Dan's) response. > > On 13/07/2018 19:26, Nikos Mavrogiannopoulos wrote: >> >> On Thu, Jul 12, 2018 at 5:23 PM, Gareth Williams >> <gareth at garethwilliams.me.uk> wrote: >>> >>> Hi, >>> >>> I've just installed and configured ocserv. I'm using openconnect as a >>> client on two Windows 10 laptops. If I attempt from, say, a hotel xDSL >>> network, I connect and am able to access my lab environment remotely. >>> >>> However, if I attempt to connect by tethering the laptops over a mobile >>> network, it fails with: >>> >>> SSL connection failure: Error in the pull function. >>> >>> I've tried connecting with gnutls-cli and this fails with: >>> >>> *** Fatal error: The TLS connection was non-properly terminated. >>> *** Handshake has failed: The TLS connection was non-properly terminated. >>> >>> If I use gnutls-cli-debug, it tells me that it it has to disable all SSL >>> and >>> TLS before exiting with: >> >> That's interesting. Which version of gnutls is that > > This is gnutls v3.5.8 on Debian 9 (and I've tried Raspbian too) >> >> and what do you >> see if you try to connect with gnutls-cli? > > > gnutls-cli --no-ca-verification vpn.my.domain.name:443 > Processed 166 CA certificate(s). > Resolving 'vpn.my.domain.name:443'... > Connecting to '146.xxx.xxx.139:443'... > *** Fatal error: The TLS connection was non-properly terminated. > *** handshake has failed: The TLS connection was non-properly terminated. > >> Do you have the capture of >> a failed openconnect session to send me? > > > All the following captures are over the mobile network. > > This is a capture of traffic at the client (running openconnect): > > ... > > This is a capture at the server end for the above: > > ... Well this is fascinating. Synopsis of your first two captures above, simultaneously on client and server? Client side (running openconnect built with GnuTLS): 14) Send: SYN [Seq=773288135] 15) Receive: SYN,ACK [Seq=688983551,Ack=773288136] 16) Send: ACK [Seq=773288136] 17) Send: ClientHello [Seq=688983552, Ack=688983552] 18) Receive: RST,ACK [Seq=688983552, Ack=688983552] Server (running ocserv): 1) Receive: SYN [Seq=773288135] 2) Send: SYN,ACK [Seq=688983551,Ack=773288136] 3) Receive: ACK [Seq=773288136] ** Missing receipt of ClientHello ** 4) Receive: RST,ACK [Seq=773288136, Ack=688983552] The first three packets clearly match. The client and server are talking to each other. But then? the server fails to receive the TLS ClientHello packet, and both sides receive an RST,ACK which the other side did not send. The RST,ACK packet received by the server (#4) is especially intriguing, because it contains the Ack# for the packet that the server never actually received. Something in between the client and server is injecting an RST,ACK in both directions. Dan
