Hello everyone,
I am really desperate. I have now spent days installing nextcloud AIO with a Nginx Proxy Manager in front of AIO. The Nginx Proxy Manager is not on the same server as the AIO.
After many problems and reading reading reading here in the forum I finally got an installation that I can log in to.
At the first look into the admin settings and the security check I have the following message:
" Your remote address was identified as “127.0.0.1” and is brute-force throttled at the moment slowing down the performance of various requests. If the remote address is not your address this can be an indication that a proxy is not configured correctly. For more details see the [documentation]"
I have tried everything I could find here and on Github. Nothing works.
I made the trusted proxy entries as you described. It simply does not work. Sometimes the first scan works, but then the next scan shows the message for 127.0.0.1 again.
Before I recieving the messages for 127.0.0.1, there were first a messages for 172.29.01 and after I set this to trusted proxies there was the message for 172.19.01. After I entered these then again to trusted proxies, I now always see message for 127.0.0.1.
I hope so much anyone can help me to fix it. Please write me which informations, logs and so on do you need from my side…
I want a functional nextcloud because I will migrate from my old NAS cloud to nextcloud…
Hi szaimen,
I have read many of your articles in the last few days and they have helped me a lot, thank you very much.
I also know the one you are linked now. I did that and added meanwhile the following IPs to the trusted proxies:
172.19.0.1 = nginx proxy manager IP in docker network
172.29.0.1 = nextcloud-aoi
172.28.0.1 = nextcloud-default
172.17.0.1 = bridge gateway
Without success. What I actually did not do is this IP6 part. I did not understand where to do this with /etc/docker/daemon.json. On my host system ubuntu 22.04 this file does not exist.
Maybe any other ideas?
" Your remote address was identified as “127.0.0.1” and is brute-force throttled at the moment slowing down the performance of various requests. If the remote address is not your address this can be an indication that a proxy is not configured correctly. For more details see the [documentation}
When I log out and log in again, I am sometimes blocked. I then have to remove the BruteForce block.
The login screen says: “We have detected multiple invalid login attempts from your IP. Therefore your next login is throttled up to 30 seconds.”
Despite this message, it sometimes works to log in again directly.
EDIT:
I installed now completely new from scratch.
Immediately after the setup and the very first time I open the login from the AIO setup wizard, I get the message
“We have detected multiple invalid login attempts from your IP. Therefore your next login is throttled up to 30 seconds.”
When I log in, I get
“Too many requests
There have been too many requests from your network. Please try again later or contact your administrator if this is an error.”
Can you elaborate a bit on your topology? And where your client (browser) device is when you’re running the checks in relation to both your AIO server and your reverse proxy server? Also, share a bit about how you’ve configured NPM?
The brute force protection isn’t really the cause here (it’s just impacted by it). The cause is that for some reason your Nextcloud (or proxy) configuration doesn’t match up with your topology.
On VM1 is the Nginx Proxy Manager. It is installed as a Docker container: https://nginxproxymanager.com/ It is configured as described in the Nextcloud Proxy documentation.
I am trying to install Nextcloud (v28) on VM2. There are some other Docker containers also running on VM2.
My browser is on my laptop which is in the same LAN as VM1 and VM2.
On my OpenWRT router port 80 and 443 are forwarded to VM1 where the Nginx Proxy Manager is running. The Proxy listening on port 80 and 443.
Both Docker Environment, on VM1 and on VM2, are running in “rootless”.
I can no longer log in at the moment. I can’t manage to reset the brute force message. I have already tried several IPs with docker exec --user www-data -it nextcloud-aio-nextcloud php occ security:bruteforce:reset IP
Can you tell me what I can do to remove the lock? And can you also tell me how to install the brute force app please?
EDIT: Ok got it, wrong password… now I try to install the BF APP but I can not see anythin in Adminitsration Setting
EDIT: It is the same as in my first installation…
First an IP 172.18.0.1 is reported as BF, after adding this to trusted proxies a 172.19.0.1 is reported and after I have added this to trusted proxies 127.0.0.1 is reported again. This does not go away, even if I add it to trusted proxies and I have no Bruce Force setting ins “Security”.
What device is 172.18.0.1 in your network?
What device is 172.19.0.1 in your network?
The 127.0.0.1 doesn’t make any sense to me, but it may be red herring due to the prior two IP addresses and something else.
Those IPs are coming from somewhere. They only can come from two places:
The actual client connection (though it may not be the real client IP address if NAT is involved)
Any intermediate reverse proxies
And BFP also only kicks if there are invalid login attempts appearing one one of the authentication endpoints within Nextcloud from for each of those IP addresses. (However BFP does rely on the source IP address it’s provided in order determine the where the brute force attempts are coming from to penalize that IP address).
So you have two problems:
something is generating significant invalid login attempts in your environment
the IP address provided to Nextcloud is likely incorrect
Hello, it is as follows:
172.18.0.1 = the network “nextcloud-aio” from VM2
172.19.0.1 = the network “nginx-proxy-default” of VM1
I have now spent quite a while in the Nextcloud and kept running the scan in “Overview”. Currently there is actually no longer a message for 127.0.0.1. Can that be? Could it be that my trusted_proxy setting only has an effect after a while? I have not restarted yet but only made the trusted_proxy entry with docker exec --user www-data -it nextcloud-aio-nextcloud php occ security:bruteforce:reset 172.18.0.1
and docker exec --user www-data -it nextcloud-aio-nextcloud php occ security:bruteforce:reset 172.19.0.1
and docker exec --user www-data -it nextcloud-aio-nextcloud php occ security:bruteforce:reset 127.0.0.1
Does that make sense?
I noticed something else in the Nextcloud interface in logs. I have a lot of error messages:
EDIT:
There are currently no error messages. I have now stopped and restarted all the containers… it remains… everything is fine and currently no more messages about BruteForce. I have edited the other messages so that everything is now “green” “All checks passed.”
A bit strange I think… maybe you really have to wait after the trusted_proxy entries.
I have a new question on this topic. Since I have a proxy in front of the Nextcloud, I now always arrive at the login with the same IP, i.e. 127.0.0.1 in my case, right? Since this IP is entered as a trusted proxy, is the BF function now in principal disabled? Also anything I might want to do with geo IPs in this Nextcloud instance I can’t use? Is that correct?
What security measures can I use to secure my login now?
Not necessarily, you can and should configure the proxy in such a way that it passes on the IPs of the devices that have made the requests to the Nextcloud server.
It probably makes more sense to do geoblocking on the proxy where the requests land first, rather than in the application behind it that you want to protect. Also, if you are running multiple applications behind that proxy, it doesn’t make a lot of sense to configure geoblocking in each of those applications separately, not to mention that many applications don’t offer such a feature.
Thank you very much for your answer. My OpenWRT router forwards port 80/443 to the Nginx Proxy Manager. Does the proxy even know the external IP or is it always just the IP from the router? Do you know that? In any case, you are right, it makes much more sense to configure everything on the proxy.
If the requests are coming from the Internet, then yes, it should see the actual IP that made the request. If the requests are coming from your local network, then it depends:
If you are using the FQDN e.g. cloud.yourdomain.tld on your LAN, and you don’t have a local DNS server in place to resolve the FQDN to the local IP of your proxy, then your router is probably doing NAT loopback/NAT reflection. And yes, in this case the IPs in the requests will be rewritten and the proxy will only see the IP of the router instead of the IP of device that made the request.
But again, this only applies to requests from the local network. For external requests forwarded to the proxy via port forwarding, the IP in the request will not be rewritten, so geo-blocking should actually work.
