[squid-users] ERROR The requested URL could not be retrieved

[Amos Jeffries]

On 30/10/18 4:23 AM, Stephen Borrill wrote:
> On 29/10/2018 15:20, Uchenna Nebedum wrote:
>> Good Day All,
>> I have setup squid 3.5 with mikrotik, and ssl bumping is enabled. after
>> accepting the certificate on the browser prompt, Squid throws an error
>> on the browser, "*unable to forward this request at this time.*" it
>> throws this error for http sites as well. please what could be causing
>> this error.
> 
> never_direct allow all
> 
> How is your proxy meant to forward on requests? You have no cache peers,
> but have told it never to go direct (i.e. always use a cache peer).
> 
>> *Please find attached my squid.conf*

There are some other issues I can already see which will be coming up
when you resolve the above problem:


>> visible_hostname localhost

Any other proxy calling itself "localhost" will cause forwarding loops.
Either let Squid locate the proxy machines hostname automatically, or
configure a FQDN for the above. The name used should resolve to the
proxy IP when clients look it up in DNS.


>> acl step1 at_step SslBump1
>> acl step2 at_step SslBump2
>> acl step3 at_step SslBump3
>> ssl_bump peek step1 all
>> ssl_bump stare step2 all
>> ssl_bump bump step3 all

The lines above contain other non-splice actions required to always
happen at every step of the SSL-Bumping process.

So these splice lines will never happen:

>> ssl_bump splice localhost
>> ssl_bump splice all


>> via off

Removal of via is only a bandaid to make those forwarding loops created
by visible_hostname not be visible anymore. They can still happen and
annoy other admin elsewhere on the networks your traffic goes to.


>> forwarded_for on
>> request_header_access From deny all
>> request_header_access Cache-Control deny all
>> request_header_access Keep-Alive deny all
>> request_header_access Other deny all

Er, the above *only* affect requests sent to upstream servers.

Removing Cache-Control in particular is definitely going to lead to
major problems for your clients.

"Other" is also tricky. It removes all HTTP headers which Squid has not
explicitly bee coded to understand.

So removing headers with "Other" like this a) breaks any modern HTTP
features your Squid does not explicitly support, and b) lets through
many headers you probably don't want to just because Squid does "know" them.

Keep-Alive is unnecessary since Squid already removes that problematic
header on sight.


>> reply_header_access Set-Cookie deny all
>> reply_header_access Set-Cookie2 deny all
>> reply_header_access Other deny all

>> adaptation_access greasyspoon allow all
>> dns_timeout 30 seconds
>> dns_v4_first on
>> #ecap_enable off
>> icap_enable on
>> icap_preview_enable off
>> icap_preview_size 2048
>> icap_persistent_connections on
>> adaptation_send_client_ip on
>> adaptation_send_username on
>> icap_service greasyspoon respmod_precache icap://127.0.0.1:1344/response
>> bypass=0
>> refresh_pattern ^ftp:        1440    20%    10080
>> refresh_pattern ^gopher:    1440    0%    1440
>> refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
>> refresh_pattern .        0    20%    4320
>> shutdown_lifetime 10 seconds/
>>
>>

>>
>> please i'll provide any other information required. please i really need
>> help. I noticed my last two questions weren't answered, i really need
>> help. I've noticed google and facebook are reachable.
>>

Meaning traffic to those does not go through the proxy or any of the
ports you are intercepting. Probably via QUIC or similar non-HTTP(S)
protocol.

If you are trying to do those weird header changes for privacy or
anonymity their traffic working is a very bad sign.

Amos