Whitelisting IPs leads to 403 errors on logout

Sounds like your IP address has changed. Your ISP dynamically changes your Public IP address on a regular basis. If 3 octets of your IP address are always the same: 99.88.77. and only the 4th octet of your IP address changes regularly: 99.88.77.66, 99.88.77.65, etc then you can use 3 octets of your IP address. If your ISP changes the 3rd octet regularly then you will have to use only 2 octets of your IP address: 99.88.

General question/general answer provided resolved.

Thanks for the answer but I have a static IP, as do the other people with whitelisted IPs who are experiencing the same problem (and they are in different cities i.e. using different computer equipment etc).

The problem also coincided with updating to version 49.2. I rolled back temporarily to 49.1, but that made no difference (perhaps because any change to the htaccess file introduced by 49.2, which might have caused the unwanted behaviour, remained when the plugin version was rolled back?).

Can you offer some more advice on what I can do/information I can provide to resolve the problem?

Post your IP based code so I can see what it is doing. BPS will only update its own code and not change any other custom code that you have added.

This the code I have in the BPS Custom Code area (specifically, in the CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE section). I included the code in the Custom Code area rather than writing it directly into the htaccess file so I don’t have to re-edit my htaccess file every time BPS is updated. Until I experienced my current issue, the code has not caused any issues with logging in/out since I started using it several months ago.

<FilesMatch "^(wp-login\.php)">
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx
Allow from yyy.yyy.yyy.yyy
Allow from zzz.zzz.zzz.zzz
</FilesMatch>

The 3 static IPs I have in this code are those for the server IP and 2 public IPs.

Having experienced the log in problems described in this thread, and having been alerted to this BPS Forum thread when I recently upgraded to 49.2, as an experiment I tried using the following code from that thread (in the same Custom Code section) instead of the code I’d previously been using:

# Protect wp-login.php from Brute Force Login Attacks based on IP Address
<FilesMatch "^(wp-login\.php)">
Order Allow,Deny
# Add your website domain name
Allow from (my domain name is inserted here)
# Add your website/Server IP Address
Allow from xxx.xxx.xxx.xxx
# Add your Public IP Address using 2 or 3 octets so that if/when
# your IP address changes it will still be in your subnet range. If you
# have a static IP address then use all 4 octets.
# Examples: 2 octets: 65.100. 3 octets: 65.100.50. 4 octets: 65.100.50.1
Allow from yyy.yyy.yyy.yyy
Allow from zzz.zzz.zzz.zzz
</FilesMatch>

Replacing my code with your code made no difference, however.

Using either “whitelist” code, logging out from the Dashboard does not complete – the browser URL reads
domainname/wp-login.php?action=logout&_wpnonce=[10alphanumericcharacters]
and the 403 page is displayed. As noted earlier, the only way to log back in is to delete the htaccess file. If I then refresh the BPS 403 page being displayed, the browser URL changes to read
domainname/wp-login.php?loggedout=true
and the login page is presented. Once logged back in, I can then re-create and re-activate BPS htaccess security mode.

I have also tested including my code on other websites I maintain and the result is the same – once logged out (or a log in time limit has expired) any attempt to log back in from a whitelisted IP results in the display of the BPS 403 page as above.

The only other change I’ve made recently to the htaccess file on my websites, is to include this code in the CUSTOM CODE REQUEST METHODS FILTERED section (as recommended when I updated to 49.2):

# REQUEST METHODS FILTERED
# This filter is for blocking junk bots and spam bots from making a HEAD request, but may also block some
# HEAD request from bots that you want to allow in certains cases. This is not a security filter and is just
# a nuisance filter. This filter will not block any important bots like the google bot. If you want to allow
# all bots to make a HEAD request then remove HEAD from the Request Method filter.
# The TRACE, DELETE, TRACK and DEBUG request methods should never be allowed against your website.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

I hope this additional information assists.

Ok there is only 1 possible thing that can be happening here. The IP addresses that you have entered/are using are not your actual IP addresses. This could be caused by using Cloud services or this could also be a routing/firewall issue. When you check the BPS System Info page are your Server/Website IP address and your Public IP addresses the same as the IP addresses you are using in the .htaccess code?

Also even though you have static IP addresses you really only need to use 3 octets of your IP address in this .htaccess code. Try changing your Public IP address from 4 octets to 3 octets: Example: 99.88.77.
Your Server/Website IP address will not change so 4 octets are fine to use. If your Server/Website IP address is being changed by Cloud services or additional Cloud IP addresss need to be added then you would add those additional Cloud IP addresses to your whitelisted IP addresses.

Thanks again for your assistance.

In answer to your first question, yes, the server/website IP address and my public IP address as listed on the BPS System Info page are identical to my entries in the .htaccess code.

I will try changing my IP address to 3 octets as suggested, and then report back.

Also just to double check what you are entering here: Allow from (my domain name is inserted here)

Are you entering your domain name in this format?
Allow from example.com

Changing my IP to 3 octets made no difference.

CloudFlare has both these IPs (all 4 octets) in its “trust” list as well.

Yes, my domain name is inserted in that format in your code. In the code I have previously been using, I only had the line with the server IP, not the domain line as well.

I am going to try one more test that has been prompted by your recent replies – I will report back shortly.

No, that faint hope didn’t pan out either ??

I have run out of ideas, I hope you haven’t!

Do you have any other .htaccess code or are using any other plugins that are blocking by IP addresses. Double check your root .htaccess file and look for any other IP address blocking code. If you have another plugin that has the capability to block by IP address at the php level then double check that plugin’s settings or if that plugin has a whitelist/blacklist check that.

Also check your wp-admin .htaccess file code for any IP address blocking code.

I do have some plugins that block by IP address but mine isn’t included. Also, those plugins aren’t installed on the other sites I tested. The problem definitely appears to be related to the .htaccess file because as soon as I FTP to my site and delete .htaccess I can log in and out normally. Similarly, as soon as I delete the few lines of IP whitelisting code, logging in/out also returns to normal. Unfortunately, from past experience I can’t leave the site open for anyone to log in because the spammers hammer the site.

Further troubleshooting will have to wait until tomorrow, sorry.