From: Daniel Lenski Date: Thu, 24 Jun 2021 06:16:16 +0000 (-0700) Subject: More complete comment about issues with proxies in connection phase X-Git-Tag: v8.20~121^2~2 X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=b821cd88f97c883aee27dbb8968f265ab7540eb9;p=users%2Fdwmw2%2Fopenconnect.git More complete comment about issues with proxies in connection phase The comment for openconnect_get_connect_url (added in https://gitlab.com/openconnect/openconnect/-/commit/ec6c0caed28ebf4f60984a49ce3122196f9c87fa) should mention the possibility that a proxy requires the correct hostname at the TLS layer (via Server Name Indication, SNI) as well at the HTTP layer (via 'Host' header), in order to correctly forward it to the VPN server. See https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/46 for a case where the 'Host' header was apparently required. Signed-off-by: Daniel Lenski --- diff --git a/openconnect.h b/openconnect.h index 8dcccc8f..465a86cf 100644 --- a/openconnect.h +++ b/openconnect.h @@ -488,8 +488,10 @@ const char *openconnect_get_dtls_compression(struct openconnect_info *); * * Later still, Legacy IP addresses got scarce and SNI was invented, and * we started to see servers behind proxies that forward a connection - * based on the SNI in the incoming ClientHello. So returning just the - * IP address from openconnect_get_hostname() now made things break. + * based on the SNI in the incoming ClientHello (TLS layer), or based on + * the 'Host' header in the initial connection-phase request (HTTP[S] + * layer). So returning just the IP address from openconnect_get_hostname() + * now made things break. * * So... we need to pass *both* the actual hostname *and* the IP address * to the connecting openconnect invocation. As well as the port.