Fresh new install of NC28.0.2/Ubuntu22LTS/10.6.16-MariaDB/php8.3/Nginx
Hi all
I finally had to do a fresh spanky new install.
Have pretty much everything fixed in the Administration Settings > Security & setup warnings.
Except for this one
* Your remote address was identified as "192.168.1.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 ↗](https://docs.nextcloud.com/server/28/go.php?to=admin-reverse-proxy).
Can’t figure out what exactly what is going on or how to fix it
I believe that the desktop and mobile are not connecting because of this error too.
You need to activate remoteIP if using Apache and add trusted proxies. That address is your gateway/router. If you would like to see the actual Remote IP you have to activate the proxy protocol.
Dependant on your setup, you will have to plan your steps. Which webserver are you using for example?
If using NGINX then it is a little easier to accomplish. But please search on Google to find the correct solution, as I EO not use NGINX so I do not know the correct commands and configs.
If using Apache2, then have a look at the RemoteIP module. I found the solution by carefully Reading the documentation. Any example I found was useless as I use a reverse proxy in front so I needed to support proxy protocol v2 and my config then looks a bit different than yours.
We don’t know whether @Traffle is using a reverse proxy, but from the very little information provided, it looks to me like a standard manual setup on a LEMP stack. So if I had to guess, I’d say this is caused by NAT reflection / NAT loopback.
If you are using a public domain name to access your server from inside your local network, the clients contact an external DNS resolver that points the requests to the public IP address of your internet connection. If port forwarding is enabled, the router will then re-write the packets to the internal IP address of your server, which make the requests appear to orignate from your router instead of the IP of the actual device that sent the requests.
The solution is to set up a local DNS resolver that will point all requests for your domain name from devices on your local network to the local IP address of your server.
True. But it will still not do him any good to get the originating IP with an internal DNS resolver, for any hits comming from public. On most routers you would not need to manually define masquerade (consumer grade) as most does that be default with all port forward rules made in a gui. However if for some reason this is not happening, RemoteIP is the solution.
Correct that when he comes from LAN, an internal DNS would help (and has other benefits aswell).
However the RemoteIP solution accommodate both source adress ranges.
If his gateway does not do masquerade then RemoteIP. If gateway do masq, internal DNS is - by far - the recommended solution.
They won’t, because NAT loopback/NAT reflection, which likely causes the problem in the first place, only comes into play for local requests.
However, if he uses a reverse proxy, then he must of course do both, forward the remote IP from the reverse proxy to the web server on the Netxloud server and set up a local DNS resolver that points to the local IP of the reverse proxy.
There are also other things he could do, like manully copy the certs from the proxy to webserver on his Nextcloud server and then point to that locally instead of the reverse proxy, which would still require a local DNS resolver, or he could use the IP instead of the domain locally, with a self-signed certificate or plain HTTP, but these aren’t good solutions imho.
No. For reverse proxy you just do TLS passthrough. Then the TLS connection only terminates on the NC webserver.
What I meant is that for trafic comming from public and goes through the gateway, then if it dont do masq, the connection will always Seem to come from gateway and not the actual public IP.
I think you’re getting a few things mixed up here. Masquerading is normaly used to rewrite the source IP address of outgoing packets so that it matches the public IP address of the gateway instead of the local IP address of the device that initiated the connection.
Incoming traffic is not geting masked by default, so a locally hosted server can always see the public IP address of the gateway or device from which the request was sent.
OP’s issure is either caused by NAT reflection (because the source IP of 192.168.1.1 most likely belongs the router/gateway) or in theory it could also be a wrongly configured reverse proxy, as you said. But my money is on the former
Thank you for all your input, Finally had a chance to get back to this server,
Based on your guy’s input I figured out that I had bruteforce app enabled, then proceeded to continually bruteforce my new installation while fixing the errors coming up in the Administration Settings > Security & setup warnings.
By just backing off for the day, this particular error stopped by itself.
