XF 2.2 [solved] 403 but no block present?

Black Tiger

Well-known member
This is an odd one. One of my users contacted me he can't visit my forums. Still running 2.2.13.
No lock on him, no ip ban, nothing. He can visit my forum though via a VPN.

It's not a server issue as he can visit other sites hosted on the server without problems.
I can manage this server and check the server error log and then I see this:

1 line with client denied by server configuration to private_html and directly below this one:
Code:
 [remote 37.6.xxx.xxx:53997] AH01797: client denied by server configuration: /home/user/domains/mydomain.org/private_html/service_worker.js

It's a Directadmin server, don't look at the private_html because that is a symlink to public_html and does not give issues.

I checked my .htaccess but the 37.6.xxx.xx ip was not in there, neither is a 37.6.xx.xx range.

Since the issue is only on my forums I don't know where it goes wrong. I had some 37.xx.xx ip in IP block in ACP but I removed that one so that should give no issues. That was 37.46.115.0/24 so it wasn't 37.6.xx.xx.

Last time he visited my forums with this ip was (as far as I could see) end of november, he didn't log in for a few weeks.

So what is the service_worker here doing with the 403. Why is there a 403 while there is no ip ban.
Anybody a clue on where to look or what is causing this strange block?
 
Solution
Fixed.

Don't ask me, users could log back in, I just put the .htaccess back as above and now nobody is blocked anymore.

And none of these ip ranges (especially not ipv6) were blocked on server level.

Spooky Holidays it seems. :)

Edit: LoL. After some time some people could visit, and very few not. But I found the culprit.
A stupid typo in the list.
46.242.0.0/1
should have been /19 and the 9 was missing, most likely causing this very odd behaviour.
OK so this is an odd one. Is this some service_worker.js bug or something?

I removed the ip list which was in the .htaccess file for a very long time like this:
Code:
deny from 5.3.180.0/22
# deny from 37.139.53.0/24
# deny from 37.204.0.0/16
deny from 45.80.106.0/23
deny from 45.86.200.0/24
etc.
and now he can login again without any issues. While his ip isn't and wasn't even in this list and others had no issues visiting the site.
 
If removing the ip from htaccess has fixed it then it points to a server not a xenforo issue.

It also looks like his IP is in the range if unblocking the range has allowed access. Have you confirmed the ip address he uses with him?
 
Have you confirmed the ip address he uses with him?
One should say it's some .htaccess issue indeed, normally that would be my first thought too. But how?

As I stated, his IP is -not- in any range.
As stated, this .htaccess was in use for a long time. And he could login before months ago with the ip in the 37.6.x.x range too.
I might have added some ip this week, but certainly not in his range and if I had made a typo, the server would have given an error 500.
And yes I checked and validated his ip.
I posted the beginning of the ip list in .htaccess file, which I make in alphabetical order in .htacces for better overview, neither his ip 37.6.x.x or any range in that neigborhood was present in .htaccess.
It was not in any blocked range on the ACP.

So now he was able to login and so I doublechecked the ip and it is indeed the ip he has given me, so that 37.6.x.x ip 100% correct.
Which is the reason I wonder what the service_worker.js has to do with this?
Additionally... I've seen 84.x ip's from kabelfoon being rejected, while not in the block, also with service_worker.js as reference.

This is the complete list I removed:
Code:
deny from 5.3.180.0/22
# deny from 37.139.53.0/24
# deny from 37.204.0.0/16
deny from 45.80.106.0/23
deny from 45.86.200.0/24
deny from 45.95.233.0/24
deny from 46.3.144.0/22
deny from 46.242.0.0/1
deny from 62.84.96.0/19
deny from 63.141.224.0/19
deny from 63.141.240.24/29
deny from 80.70.110.0/23
deny from 83.139.128.0/18
deny from 83.220.238.0/23
deny from 80.94.27.0/24
deny from 91.210.248.0/24
deny from 95.84.128.0/18
deny from 95.158.43.0/24
deny from 95.181.149.0/24
# deny from 113.160.0.0/11
deny from 120.0.0.0/12
deny from 149.34.0.0/16
deny from 154.6.0.0/16
deny from 154.202.100.0/24
deny from 157.97.120.0/24
deny from 157.97.121.0/24
deny from 159.48.55.0/24
deny from 165.225.192.0/18
deny from 171.224.86.0/24
deny from 172.252.1.0/24
deny from 178.66.0.0/16
deny from 182.176.3.0/24
deny from 183.192.0.0/11
deny from 185.156.75.0/24
deny from 190.86.0.0/16
deny from 193.38.235.0/24
deny from 193.233.0.0/16
deny from 194.169.217.0/24
deny from 199.168.96.0/21
deny from 212.102.48.0/24
I don't see anything wrong, but I might be staring blind on something.

Edit: I see I had 1 80.x block not in alfabetical order, but the rest is.
 
Well it's getting more funny now and strange, since now more users were able to login and reply to my thread about having fixed this om my forums.

One uses a ipv6, which is not blocked here in this list!
Another one a 109 ip which is also not blocked in this list!

Then the most interesting thing came, another user answered and he wasn't able to login with W11 but he was able to login with W10.
Another with with a 84.17.46.xx VPN ip which is also not in this list.

And all of this while it worked until yesterday with this same .htaccess without any issue, so it can hardly be a .htaccess issue.
Which makes me think this can ot only be a .htaccess issue because ip's not even in there were blocked.

However according to the users most were using Firefox. Maybe it is or was related to the new Firefox update. I don't know.
Or maybe opcache, could that cause something odd like this too?
 
Fixed.

Don't ask me, users could log back in, I just put the .htaccess back as above and now nobody is blocked anymore.

And none of these ip ranges (especially not ipv6) were blocked on server level.

Spooky Holidays it seems. :)

Edit: LoL. After some time some people could visit, and very few not. But I found the culprit.
A stupid typo in the list.
46.242.0.0/1
should have been /19 and the 9 was missing, most likely causing this very odd behaviour.
 
Last edited:
Solution
Top Bottom