On Thu, Jul 12, 2018 at 8:23 AM, Gareth Williams <gareth at garethwilliams.me.uk> wrote: > Using Wireshark shows that the server returns a RSK, ACK to the client's CLIENT HELLO message; while messages in ocserv log (jounralctl -xe) shows the client has disconnected unexpectedly. Are you running Wireshark on the server or on the client? (I assume on the client.) It would be valuable to run Wireshark or tcpdump on the other end as well, to confirm whether the RSTs are actually originating on the server, or getting injected by some middlebox. > This suggests the mobile network is sending the reset, but that doesn't explain why openssl s_client connects successfully over mobile networks. Assuming that the RST is indeed injected by the mobile network, and not originating from ocserv itself? does the client actually receive the *same response* to an openssl HELLO *and* to a gnutls HELLO? I've used openconnect+GnuTLS while tethered on at least 5 different mobile networks around the world, and have never run into this? but it seems plausible that the mobile network is doing passive TL fingerprinting of the CLIENT HELLO and injecting a reset only in response to gnutls. I'm going out on a slightly conspiratorial limb here, but GnuTLS isn't nearly as widely-used as OpenSSL and it's possible that the GnuTLS fingerprint "looks like" some software that the ISP doesn't approve of (e.g. P2P file-sharing software). It wouldn't be the first time that an ISP is observed to inject RSTs selectively against certain clients (https://en.wikipedia.org/wiki/TCP_reset_attack#Comcast_Controversy). Dan