Domain was set up with DDNS with AIO’s built in services, no external reverse proxy or tunnel. No issues during this validation.
Today, I tested the login page with incorrect credentials. This triggered the brute force warning, so I looked at the admin settings and console. I noticed that the remote ip showed as the 127.0.0.1 loopback ip. I went on my phone on cellular data, same remote ip at 127.0.0.1.
It seems that for some reason, the source ip is not being passed to the nextcloud server correctly, so it identifies all requests as coming from this ip. This means that if my server were truly brute forced…legitimate users may be denied access, and of course will make it impossible to track and block malicious IPs.
It seems this must be a bug of some sort. No external proxy is being used, just a DDNS domain, and port forwarding to the AIO server. No issues were shown during the domain validation step. Basically, everything should be the default config. But, if there are any settings that might affect this, I am happy to look at those as well to try to figure this out.
Not a bug per se. The baked-in reverse proxy in the AIO is either not adding the X-forwarded-for header or the web server serving Nextcloud is not configured to read that header.
Did you also publish port 443 or are you accesing NC by 8443 or 8080?
I’m not too familiar with the technical details…but why would that header be omitted or be configured to not read it? It reduces the utility of brute force protections and it would make it impossible to track malicious IPs. It doesn’t seem like an intentional configuration.
In any case, any idea if I can make changes on my setup to get this to work?
I’ve port forwarded 80 and 443 and I access with the DDNS domain only.
It’s not omitted. This is all pre-configured in AIO so it should work.
Do you have any errors under Admin settings->Overview (other than brute force throttling presumably)?
Can you confirm your internal network topology doesn’t route/filter anything thru another container/VM or anything like that (i.e. a co-hosted firewall running on your container host)?
Also any use of VPN/Tailscale/Cloudflare/etc?
Can you post the output of docker network inspect nextcloud-aio?
I’ve looked into it a bit more and I think it’s an orbstack limitation in macos (unless someone else is running on orbstack without this issue).
Either way, I’ve enabled the max login attempts too and I am satisfied with the level of security. I have yet to see an unauthorized login attempt, which is surprising considering my simple ddns domain.