Hi Amos, Here is the topology: client (curl from host running docker) --> squid_child (docker, using ssl-bump with intercept) --> squid_parent (VM with internet connection, https_port without ssl-bump) --> origin server.
local - 72.19.0.2:443 is the container running squid child remote - remote=172.19.0.1:44522 is the host machine where containers are running, I am using a curl to do initial tests. Eventually, request would come from other containers or external hosts on the docker daemon host. With http traffic this works fine; wherein the request is forwarded to Parent and then to origin server. However, with https header forgery kicks in and tls is terminated. - Kedar On Mon, Jun 18, 2018 at 9:44 AM Amos Jeffries <squ...@treenet.co.nz> wrote: > On 18/06/18 02:08, Kedar K wrote: > > Hello, > > > > I am hitting this issue when running squid in a docker with ssl parent > > cache_peer. > > > > Can you describe that a bit clearer please? An end-client, two proxies > and origin server makes four HTTP agents involved with this traffic. > > Which of those proxies (and/or server) is inside the container? > > And how are you getting the traffic from the client to the first proxy? > > > > Host header forgery detected on local=11 72.19.0.2:443 > > remote=172.19.0.1:44522 > > FD 15 flags=33 (local IP does not match any domain IP) > > > > The host ip of the docker would not resolve to a domain. How to > > work-around this problem? > > The agent being client for the proxy reporting this message apparently > thinks there is a origin server running at "72.19.0.2:443" hosting some > domain name. They are trying to contact that origin server. > > > > Amos > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > -- *- Kedar Kekan*
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users