Hi @yitwail, thanks for providing me a detailed description of what you’ve tried so far.
This, on the face of it, sounds like outbound or inbound connectivity issues which usually would be a server setting that your host can help you out with. However, we can look at your diagnostics to try and find the root cause to see if there’s anything you can do yourself to remedy this from within WordPress or Wordfence.
Can you send a diagnostic report to wftest @ wordfence . com so that we can advise you further? You can find the link to do so at the top of the Wordfence Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.
Note: For the fastest response time, please make sure and add any information or questions directly to this topic and not the email address above unless asked.
Thanks,
Peter.
@wfpeter Thank you for your response; I just sent the report.
Hi @yitwail,
I can see the cURL error 7 in your diagnostics. We have seen these before but they’re not incredibly descriptive. As I mentioned before, there is definitely a connection issue from your site to our servers and back. I have reviewed a case recently where connections were disallowed by a firewall on the server.
Could you please consult with your hosts or server administrator over any reason that ports 80 and 443 might be experiencing this firewall blocking? The specific error messages for your reference are below:
wp_remote_post() test to noc1.wordfence.com failed! Response was: cURL error 7: Failed to connect to noc1.wordfence.com port 80: No route to host
wp_remote_post() test to noc1.wordfence.com failed! Response was: cURL error 7: Failed to connect to noc1.wordfence.com port 443: No route to host
You may also need to whitelist our IP range, which for your reference is 69.46.36.0/27
Let me know how you get on.
Peter.
@wfpeter I’ll try whitelisting your IP range, though as far as I know, it’s not blacklisted. Also, one reason I doubt it’s simply outbound connectivity is because in the sample PHP code I included earlier, if I change your URL, http://noc1.wordfence.com/scanptest/hilowebdesign.com/wp-admin/admin-ajax.php?action=wordfence_doScan&isFork=0&cronKey=47e9d1fa6a675b5999999333 to http://www.example.com/ then the code works.
ETA: I added 69.46.36.0/27 to both /etc/csf/csf.allow and /etc/csf/csf.ignore and restarted csf, which should whitelist the IP range, but it didn’t have any effect. I’d rather not have to switch to a different security plugin, so I hope you can suggest something else. Also, not sure how helpful this is, but when I ping 69.46.36.28 I get timeout, both in my computer connected to wifi and in my smartphone ping app when not connected to wifi, and lastly, I checked 69.46.36.28 at MultiRBL http://multirbl.valli.org/dnsbl-lookup/69.46.36.28.html and it’s listed 6 times, though whitelisting your range should make that moot.
-
This reply was modified 4 years ago by yitwail.
-
This reply was modified 4 years ago by yitwail.
Hi @yitwail, thanks for the extra information.
Our servers don’t respond to pings so that’s an expected outcome. This has to be an issue at the host and I feel you should contact their support channels to explain the issue, because we’re not seeing the same traffic issues from our sizeable user base.
Thanks again,
Peter.
@wfpeter, in my original post I mentioned I had already contacted the data center, limestone networks, and their response was,
It seems issue with remote “noc1.wordfence.com” security setting/policy which is in-accessible from external network and from your given server.
Is it possible that our server IP is blacklisted by your firewall? If so, is there anyway to check that, and perhaps have the IP whitelisted?
Thank you.
Hi @yitwail, thanks for your response and our development team have taken a look into your issue.
traceroute -M tcp -p 443 XX.XXX.XX.XXX
works from NOC1 in 19 hops. In AWS, traceroute -m 40 -M tcp -p 443 XXX.XXX.XXX.XXX
is intermittent. It’s definitely an issue outside of our network as it seems to be dying when it reaches the servers where your site is located.
If your host tries the same method with TCP to our servers to see if the process dies earlier, then the problem may be able to be identified. The IP where it died for us is 190-63-143-63.static.reverse.lstn.net, which appears to belong to your host.
Thanks,
Peter.
Thanks,
Peter.