Problem with recognizing and blocking IP addresses

Here’s the situation. We are seeing complaints that AVH is blocking access to site – claiming the IP address is listed in StopSpam or Project Honey Pot. The problem is – the IP address being shown as blocked is *not* the IP address being used to access the system.

For example:

Access has been blocked.

Your IP [109.230.246.194] is registered in the Stop Forum Spam or Project Honey Pot database.

If you feel this is incorrect please contact them

Protected by: AVH First Defense Against Spam – WPMU DEV Version

If we review the IP address, it belongs to a German ISP and is indeed blocked in StopSpam.

However, the static public IPs being used to access the site are 173.67.xx.xx or 12.159.xxx.xxx (first being Verizon and the second being AT&T.)

Smartphones that received this alert were using an Easton Utilities connection who’s IP address was 69.2.xxx.xx.

None of these IP addresses have anything to do with the German IP address that was being listed as the one being blocked.

This is only one example, but exemplifies the problem. Why is this happening? What can be done to stop this?

  • DavidM
    • DEV MAN’s Mascot

    Hi johnol,

    That’s definitely strange and I don’t recall seeing anything like that before. I’ll ask the developer to have a look here as well, but to help get this sorted could you let us know what versions of WordPress and the Comment Spam Pack you’re using?

    Thanks,

    David

  • johnol
    • Site Builder, Child of Zeus

    We are running Multisite 3.2.1 and AVH 2.0.1. We are using WP Super Cache.

    Separately, is there a way to control the content of the messages displayed / sent to our customers without needing to edit the plugin itself?

  • DavidM
    • DEV MAN’s Mascot

    Hi johnol,

    Thanks for the additional information. I wonder if WP Super Cache has anything to do with it. Would it be possible to deactivate that momentarily to test it?

    As for the messages, I believe that would have to be done in the plugin code itself at this time. I’ll mention that to the developer as well, who can have a look at that once he gets a clear moment.

    Cheers,

    David

  • johnol
    • Site Builder, Child of Zeus

    Well – the problem is – the problem itself is a ghost. It comes and goes. So there’s no way to know for sure even if we deactivated Super Cache. We need the caching enabled – can’t live without it – but we are using the PHP method and not the .htaccess method for Super Cache to handle the requests. So far this has maximized compatibility / flexibility.

    We’ve turned off the “3rd party” options within AVH for the time being until your team has a chance to evaluate and let us know…

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.