Hi everyone.
I been using Ipfire for many years (ipcop too) and the last month we have problems with a goberment site that uses ReCaptcha. Users behind Squid proxy cannot validate and keeps trying select image page at least 20 times, finally says that recaptcha has temporary blocked because of a bot is behind my network.
I´ve searching for this issue trough all web and nothing similar have found. I have 200 users aprox in squid, trying to use this site.
I put all related sites (gstatic.comgoogle.com etc) in NON CACHE but anyway still the same issue.
Any help must be appreciated
could you check Squid logs when this happens and post them here? Can it be that is not squid the problem but some of the IP based blocklists IPFire is using (geolocation, suricata etc…)? Maybe you should check also the kernel logs as well.
Ip geolocation is disable.Intrusion detection is enabled
This happens on sites that are frequently accessed by users, other sites that has recaptcha don´t fail. Here are some logs of access.log
According to your logs, you have incomplete transaction headers between the reCAPTCHA server and squid.
TCP_MISS/200 means the following: the requested object was not available in the Squid cache (a cache miss), so the proxy server fetched the content from the origin server, and the request was successful with a 200 HTTP status code.
error:transaction-end-before-headers means that the connection was closed before the complete HTTP headers were received from the origin server or client.
Can you clarify this statement?
You are saying that there are clients with less traffic passing the captcha test, while others with more traffic won’t?
If that’s the case, three possibilities come to mind:
Rate limiting: Google may impose rate limits on reCAPTCHA requests. Clients with more frequent access might be hitting these limits, causing their requests to be blocked.
Caching issues: squid might serve a cached page when the request turnover is higher, which might trigger the problem; in this case you could prevent the caching of the domains serving reCAPTCHA. You could prevent caching using ACLs. For example in /var/ipfire/proxy/advanced/acls/include.acl you could add something like this:
This will create an access control list (ACL) for reCAPTCHA domains and deny caching for them. This way the content will always be served “fresh” (so to speak) by squid. I believe though that this is NOT what is happening to you, I think, given the logs.
IP reputation: Clients with more frequent access might trigger an IP addresses flagging by Google, causing reCAPTCHA challenges to fail. Your clients have all the same public IP?
You are saying that only one destination server challenging your user with recaptcha, is not working since a month or so, while others using the same technology (reCAPTCHA) instead are working? did I get it this time?
No Ip address blocking.
URL filter is configured but log dont show anything about recaptcha related sites when this happen to a client.
Users with unfiltered access has the same issue.
Maybe this is just a rate limiting issue. Maybe too many connections from the same IP address. Did the number of access attempts increase in the last month?
Also, did you test if without squid the reCAPTCHA works?
With default gateway, firewall green to red without limits, sometimes pass and sometimes shows pictures for 15/20 times (to select motorbikes, cycles, etc)
Likely the problem is coming from the two destination sites. More I think about it and more I believe is them rate-limiting your IP address. Can you contact them and ask if they are rate limiting your IP?
Yes, I´ll do. I’m running out all possibilities because here government sites are well known for not giving or delayed support replies.
I´ll let you know. Thanks!!
you should briefly test removing the proxy as well, just in case there is something we are overlooking. I mean, you see the problem, remove the proxy, connect directly, still a problem? If yes, IP rate limiting supported. If not, we are overlooking something on the proxy side.
