Scans not starting automatically

The way WordPress works by default, is that it’s internal “scheduling” process, called “WP-Cron” gets called during normal user visits. It will wake up when a user visit a page, and suddenly start doing various maintenance things, while that user waits to see their page. 🙂
That works OK for things that complete in split seconds, but you sure would not want a user to get caught by suddenly running a long “WordFence Scan”, while they wait to see your page.

To prevent that from happening, WordFence does not merely use Wp-Cron, but starts it’s various tasks by instead “calling back” to the server to create it’s own “visit”, where things like the file-scan can happen in peace and quiet, leaving your normal users to go about their own business.

THAT then means that your site has to be able to call itself to accomplish various tasks. If it tries to “call home”, but the call cannot go through, tasks start failing.

Your diagnostics output state directly, that this cannot happen because of an issue with your hosting setup.

“Failed to connect to (domain here) port 80: No route to host“.

Your site’s server cannot figure out how to find itself. It cannot translate your domain-name into a “route” (path through the networks) back to it’s own IP address. It is usually caused by a local configuration issue, which I have seen on some server/hosting setups.

It for example can happen, if your server is behind a NAT (Network Address Translation) where it has a different IP-address internally from what it is known as on the global Internet).
That can make it seem alive to the external world, so you get visitors from outside, but when you try to use the external IP address (what your domain-name translates to) to call the server from itself, it fails because the server does not know that this IP address is actually itself. It essentially knows only it’s internal address.

There are various configuration changes that can fix that, including fixing routing, adding IP to interface directly, adding your host-domain-name to the local /etc/hosts file – but pointing to the loopback interface instead, …, …
BUT, unless you have root access to your server all those methods are unavailable to you directly. If you are on a shared hosting setup, you can NEVER have root access. Your hosting company would have to fix their setup.

On a VPS or Dedicated server, where you are in 100% control and have root-access, the simplest methods is usually to just add a line to the /etc/hosts file, pointing your domain/server name to loopback (127.0.0.1), since that affects only the local server. It usually fixes it, assuming that your web-server is listening on Loopback.

Starting scans remotely should theoretically work around this by making the WordFence server(s) call your site instead. It is a workaround for the call-back problem, but for scans only. If that does not happen, I guess that is another problem.

Yes, the start scans remotely should theoretically work around that problem, because the “call” then comes from WordFence’s server out on the internet, not from your server locally.
Since users (and yourself) can find the site through the domain name, so should the WordFence servers. You should then be able to see the calls from the WordFence domain into your server in your site access-logs (they will not show in WordFence’s Live Traffic).

Can’t say why the remote calls are not starting. Thats another issue, that will have to be debugged from the WordFence side. Especially, if your Diagnostics page is not complaining that it cannot call WordFence servers.

All that said, WordFence uses “call backs” to do other things besides Scans, so if call-back for scans are failing (No Route to Host), SO ARE THESE OTHER THINGS. And since they are internal tasks, not obvious like a Scan, you don’t see these failures easily.

So even if the “Start scans remotely” was working to get Scans started, you should still get the call-back thing fixed. As in, get your Diagnostics page to show clean, with everything green.

No, there should be no delay.

Does your hosting account allow SSH access to the command-line on the server? You usually have this access, since you do not need root-level access.

If so, then you can log in and confirm what is happening.

Issue command

telnet yourdomain 80

Telnet is an old-style terminal connection, not normally run on port 80 (http).
But on port 80, it simply creates a connection to the web-server after translating the domain to an IP address (if it can). The same name to IP-address translation WordFence would have to do, through WordPress.

You should see something like

Trying {your ip address}...
Connected to yourdomain..
Escape character is '^]'.

If it manages to connect and does not time-out or fail, you can in fact now “talk” to your web-server, just like a browser or WordFence would.

For example, if you type command

GET /

you are doing what a browser would do, calling for your home-page (except you are missing a lot of headers and cookies).. But your web-server should now spew out a goop of HTML code. Either with your actual home-page, or with complaints about bad access, redirect to https, or other things.

Either way, if you can connect you should be OK. If you can “talk” to it, even better as a test. (It does not matter what response it gives you to “GET /”.

Notice, that if they entered your host-name into the /etc/hosts file with your public IP address, that might not work, since that was your problem to begin with. That the server does not know it’s public address (which is what DNS returns already).
You will see the translated IP address when you do the ‘telnet’ command, or you can simply say ‘cat /etc/hosts’ and check it’s contents.

If your server is behind NAT, they will have to enter the host/domain name in /etc/hosts with it’s internal IP address, or maybe even with the loopback (127.0.0.1) address to force the server to know, that when someone calls your domainname from inside the server itself, it should NOT try to connect via the public address (the Internet), but just call itself.

BUT.. Your hosting support folks should have confirmed all this before even reporting back to you.. They know the problem, and should test the solution before telling you it is fixed. Otherwise, they must have assigned you to the latest support trainee. 🙂

If they cannot successfully do the telnet type test sitting on the server’s command line, then WordPress/WordFence will not be able to either.

Let us know, when they figure it out. 🙂

It all depends on how they set up the server.
For example, it also depends on priority of name resolution. If it ALWAYS checks DNS first, and /etc/hosts next, hen obviously /etc/hosts cannot be used to override the DNS result, like we are doing here. It would find your public address first, and look no further. But that is not too normal a setup.

In either case, they should know how to make their server call itself. 🙂

Good to hear it is now working as expected. 🙂

Life without the ability to “Call Home” sometimes.. Much less fun. 🙂