Hi Nikos and Dan, I've just managed to connect over the mobile network using IP address instead of hostname, and it worked. As my lab is behind a VDSL service without static IP, I'm using a dynamic DNS service (zzzz.io) to get a static name with which I connect.? If I access openconnect/ocserv with the <my account>.zzzz.io DNS name, it also works over the mobile network. But, as I also have registered a domain name for myself, I've setup up an alias to point vpn.<my domain name> to <my account>.zzzz.io.? This alias works for OpenVPN, but for some reason, it doesn't work for Openconnect or gnutls-cli over either of my mobile networks. This is something for me to either put up with, or work out what's happening.? Either way, it's not a problem with openconnect or gnutls-cli I don't think. I also found that if I try to access the vpn.<my domain name> with any browser, the connection gets reset.? I'd have sworn I'd tried that previously and it had worked, returning some XML.? So chances are the network provider has a middlebox here that checks 'something' on the https port and aborts the connect.? Why OpenSSL works, will remain a mystery I believe. Thank you both for your time and assitance with this issue. I've learnt quite a bit over the weekend, so it's not a complete waste of time from my point of view.? I'm sorry I wasted your precious time on it though. Kind regards, Gareth On 15/07/2018 18:48, Nikos Mavrogiannopoulos wrote: > On Sun, Jul 15, 2018 at 4:41 PM, Gareth Williams > <gareth at garethwilliams.me.uk> wrote: >> On 14/07/2018 21:06, Nikos Mavrogiannopoulos wrote: >>> Unfortunately, it is only heuristics you can try here. It could be >>> that the middlebox doesn't understand a particular extension, or some >>> particular ciphersuite, or doesn't like the hello size. Try a smaller >>> ciphersuite list as: >>> >>> "NORMAL:-SHA256:-SHA384:-3DES-CBC:-DHE-DSS:-SIGN-DSA-SHA1:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC:-CAMELLIA-128-GCM:-CAMELLIA-256-GCM" >>> >>> And/or combinations of that list (i.e., re-enabling DSS/DSA if you >>> need it). That's the list of algorithms which are already disabled in >>> 3.6.2 (some also from the unreleased 3.6.3) versions of gnutls. Would >>> that improve the situation? If not you can go further by trying >>> options for specific extensions such as %NO_ETM, >>> %DISABLE_SAFE_RENEGOTIATION, %NO_SESSION_HASH, %NO_TICKETS etc. If any >>> of these help improve the situation let me know. >> >> Hi Nikos, >> >> I tried various combinations and came to the conclusion that the only >> extension that differ between gnutls-cli working (with the >> --disable-extensions option) and failing was server_name. I then noticed >> that gnutls-cli has the --disable-sni option. I therefore tried the >> following: >> >> gnutls-cli --no-ca-verification <hostname>, and the connection failed as >> expected. >> >> gnutls-cli --no-ca-verification --disable-sni <hostname>, and it works (no >> need for Priority Strings by the way) >> >> Then, to add confusion I added server_name to openssl's s_client Client >> Hello: >> >> openssl s_client -servername <hostname> -connect <hostname>:443, and oddly >> that worked. >> >> Therefore it seems the problem is down to the server_name TLS extension but >> only when the client is gnutls. I compared the hex dumps (from Wireshark) >> of the extension from gnutls-cli and openssl s_client and they are >> identical. The only difference I noticed was the ordering of the extensions >> - when using gnutls-cli the extension is 4th in the extension list (behind >> extended_master_secret, encrypt_then_mac and status_request) while for >> openssl s_client the server_name extension is the 1st in the list. Could >> that make a difference? > Protocol-wise it shouldn't make a difference. That's very odd though, > do browsers work there? If yes, it may be that there is a buggy middle > box, or a middle box which is fingerprinting to block VPNs (the latter > you can rule out if openvpn works). > > regards, > Nikos
