GTranslate Translation Proxy IPs are blocked by wordpress.com hosting
-
Hi,
My name is Edvard and I’m the CEO of GTranslate Inc. We provide translation proxy services to website owners.
I’m writing to you in hopes that you can address the issue we are having with our customers using wordpress.com hosting service.
It seems that recently your hosting firewall started blocking some of our translation proxy IP addresses and we are receiving many complaints that they are not able to use our service.
I would like to ask you to define a trusted proxy network. Our technology is similar to what Cloudflare offers, the difference is that whatever flows through our proxy network is being translated. Our proxy IP addresses are defined here: https://gtranslate.net/ips.txt
We provide the real visitor IP address in X-Real-IP, X-GT-ClientIP and X-Forwarded-For headers, so your firewall can know the real visitor IP address and instead of blocking the proxy IP address it can block specific visitors using our proxy.
We do not guarantee that malicious requests will not reach your servers, however we guarantee that the real IP address will be provided to you with each request flowing through our network, so you can reliably block the malicious requests.
Previously I have tried to use your live chat support, but it seems that I’m unable to reach the right person.
Thank you!
The blog I need help with is: (visible only to logged in users)
-
Hi @edo888, thanks for getting in touch! I’m sure you can imagine our support team doesn’t directly control the allow lists, but I can check to see whether it was sent along to the right team. The only trouble is I’m actually not finding any previous attempts with live chat; were those under another account? Or, do you mean you weren’t able to open a chat at all?
-
Hi,
Yes, I know you are not controlling the firewall, so I have asked to direct me to the right team.
Some of our common customers have reached your live chat individually with no solution. I have spoken to your live chat on behalf of some of our customers and ask to send the message to the right team without success. I have emailed help@wordpress.com, but seems we are not reaching the right person who has control.
It seems that all our customers on wp.com hosting are affected by this issue. I’m aware of at least 7 websites on wp.com hosting affected by this issue. If there is some private channel I can share more info, actually I have done that already through email.
We have noticed complaints from our customers from 6 days ago. Before then some of the IPs were blocked and the ban was only about incoming connections. Now we see that almost all IPs are blocked for outgoing connections.
Thanks!
-
I have spoken to your live chat on behalf of some of our customers and ask to send the message to the right team without success.
Got it, we’ll see about locating the conversation some other way.
Quick question about your service: I’m guessing you have some sort of caching on that side so you’re not re-requesting the same content several times per second. If you tinker with the timing on that, do you see any differences?
-
Hi,
Yes, we do have caching on our end. Right now it looks like to be a permanent ban.
We are a pass-through service provider and we only send requests for the original version when we do not have cache on our end and there is a request for a translated page.
The number of requests from our network can be significantly more than regular visitor will send, because we serve translations for multiple customers on your hosting. That is why I’m asking to define our network as a trusted proxy, so your limits are applied not to the connecting proxy IP address, but to the real visitor IP address who is accessing a translated version through our service.
Thanks!
-
Just so I understand, are you getting each page once for all translations, or once for each translation? When you have a translation, do you still pass the traffic through your proxy to our service, or just show what you’ve cached? Do you translate each page in real-time as each person is viewing it?
I want to be clear that we can’t promise anything with regard to an allow list, but I do want to have as much information as possible to pass along with your request, especially any info regarding what you’re doing to optimize on that end.
-
Hi,
Yes, we have multi level caching. We keep original page cache and then translated page cache. If we do not have the translated page cache, but we have the original cache, we use that to translate in real time. If there is no original cache as well, then we forward the request to origin server.
I want to note that defining a trusted proxy is a common procedure. I’m sure you already have similar configuration for Cloudflare network and many hosting providers do that for our company. Some notable hosting company is Siteground which has special configuration for us.
If you need some specific instructions how it can be configured, let me know and I can provide specific instructions for your system.
The easy way is to scan our IPs list defined in https://gtranslate.net/ips.txt file from time to time and make adjustments to your configuration. However you can also make it completely dynamic by using reverse+forward DNS lookup to make sure the IP belongs to gtranslate.net network.
If for some reason you decide to not cooperate, then the only thing we can do is to ask our customers to use a different hosting company.
I personally think that the website owner has a right to decide who can access their website and who must be stopped and hosting companies must respect that. Previously some of your support agents have mentioned that since the customer is on shared hosting plan, they cannot make such decisions, which is not acceptable.
Thank you!
-
-
Hi!
Im one customer that have the issue with this plugin. You can see that my domains https://mobilanyheter.net/ko/, https://mobilanyheter.net/ja/ and https://mobilanyheter.net/zh-TW/ is completely blank if you try to open them. GTranslate have been giving my site a huge boost in traffic and if you dont fix this I will see no other alternativs then to change hosting provider.
(and for same reason I can not post from the account where I have the affected site).
Thanks!
//Rasmus -
Hi,
Thank you for the extended details about this situation.
WordPress.com is not explicitly blocking GTranslate’s IP addresses at this time. Traffic has flowing between our servers and GTranslate’s.
This issue appears to be due to something else.
We have performed some extended testing and have identified some potential issues that GTranslate may need to review and resolve.
We also found that GTranslate’s full proxy service, where sites utilize subdomains like fr.example.com — instead of example.com/fr/ — appears to be working.
Next steps
These findings have been compiled and sent over to @edo888 directly.We will continue to review things and check on updates from GTranslate / @edo888.
-
Hi,
The temporary fix will be to modify wp-content/plugins/gtranslate/url_addon/gtranslate.php file and change
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);to
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);We are working with WordPress support team to find the cause why the certificate is not being verified against cacert.pem file.
Looks like there are 2 parallel issues currently. One is blocking/rate limiting of some of our proxy IPs, the second is not using cacert.pem file for verifying the certificate during SSL connection.
Thanks!
-
Correction:
Changing
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);tocurl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);temporarily is enough while we continue the investigation.Thanks!
-
Howdy! This is caused by a bug in curl which you can see was reported here . It’s triggered when you have a certificate that only supplies the hostname in the CN field and the SAN field is empty. This behavior has has been forbidden by commercial CAs since 2012. Based on some data from Chrome which you can find in this comment, only 1.57% of private CAs rely on this CN-only behavior. We’ll deploy a fix on our side in the coming days or as an immediate workaround you can update the self-signed cert you are using to not have an empty SAN field.
-
Hi,
Thank you for the details.
We have updated our server certificates to include the hostname in SANs. Now we see the connection issue is solved for users using sub-directory URL structure.
However my initial request was about blocking our proxy IPs and I have asked to possibly define our network as a trusted proxy on your end.
While we were communication about IP blocks, it seems that you have updated the curl library on your end and this new issue appeared related to verifying certificates.
Now the certificate verification issue is solved. However I do not confirm that blocking our proxy IPs is permanently solved.
Could you comment about it?
Thank you!
-
Thanks for the update and reissuing the certificate. I also can confirm that it’s working fine now.
We did also check your concern about the IP blocks and I do not see any of the IPs in the list you provided as being blocked. The vast majority of our IP blocks are transient and are only applied when abusive behavior is detected from an IP address. At a platform level, we do not define any proxies as trusted for various reasons, but as I mentioned, I don’t see any issues with the IPs you have provided.
Does your proxied traffic all use the HTTP User Agent “GTranslate-Translation-Proxy” ? For what it’s worth I do see a decrease in traffic from this user agent when this curl issue started, but the traffic seems to have returned to normal levels since you updated the SSL certificate around 2345 UTC.
Are you sure there is still a problem? If so, maybe you can log into one of these proxy servers and run a test using curl or a similar tool and see what sort of error you receive?
-
Hi,
For googlebot, bingbot, yahoo slurp, baiduspider, msnbot, YandexBot we are changing User-Agent header to GTranslate-Translation-Proxy to avoid blocks by some firewalls which verify requests against known bot IPs. We also pass the real visitor User-Agent by setting a special X-GT-Real-User-Agent header, so hosting providers can possibly use that instead in their configurations.
For other requests we do not change the User-Agent header and do not set X-GT-Real-User-Agent header.
I’m not sure there is a block issue currently, but ideally I want to avoid that in future, so our IPs never get blocked.
We have been notified by our customer that they see the following error message when they try to open a translated page:
Firewall
Blocked because of Malicious Activities
Reference ID: …
We were able to avoid that by changing the IP set assigned to specific website. However I have noticed that after some period the issue comes back.
Thanks!
-
That error message doesn’t look like it’s coming from us. Is that error something your service returns? Maybe they are using a different service that is blocking IPs? Without the specifics it’s hard to know for sure. If you can ask them to contact our support with the details we can try to help further. Unfortunately, there isn’t a way to ensure your IPs are never blocked but I looked back through the last few months of malicious activity logs and these IPs don’t appear there, so unless something changes, it seems like things will be ok.
-
It is not our message. It is the response we get when we send requests from our blocked IP addresses.
The customer does not have any other security related plugins other than JetPack. Can it be from JetPack?
Can I somehow DM you more information?
Thanks!
-
Sure – you can ping me on WordPress Slack – I’m @barry (https://profiles.wordpress.org/barry/)
-
Hi, I have a WordPress site that uses GTranslate: aotearoajusticewatch.org.nz
The translation feature is mission critical to us, and it hasn’t been working for a number of weeks. Thanks to both parties for coming to a speedy resolution for whatever issues are causing the problem.
Cheers, Jason
- The topic ‘GTranslate Translation Proxy IPs are blocked by wordpress.com hosting’ is closed to new replies.
WordPress.com Forums 