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
<[email protected]> 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
_______________________________________________
openconnect-devel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/openconnect-devel
