What if the correct remote ip-address is not shown in the Nextcloud logs when login fails?

[szaimen]

On some instances, there might be the wrong ip-address shown in https://yourdomain.com/settings/admin/logging when a login failed. This is either caused by a missing trusted_proxy in Nextcloud or caused by ipv6 not being disabled correctly or caused by the docker network not being configured correctly for ipv6. Follow these steps to resolve it:

1. First, check the admin overview in https://yourdomain.com/settings/admin/overview if there is an ip-address shown as brute-force throttled, that should be added to the trusted_proxies list. If so, you can add it with sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ config:system:set trusted_proxies 2 --value="ip.address.that.is.shown" - of course you need to adjust ip.address.that.is.shown to the one that is shown in the admin overview. After a reboot of the Nextcloud container, there should not be any further throttling and the correct ip-address should be logged in the Nextcloud logs when login fails. If that should not be the case, see below:

If the above is not successul, you can now try to correctly configure the docker network for ipv6:

1. Stop your containers from the AIO interface
2. Enable ipv6 in your docker daemon if not already done by following https://github.com/nextcloud/all-in-one/blob/main/docker-ipv6-support.md
3. After the docker daemon started correctly run sudo docker network disconnect nextcloud-aio nextcloud-aio-mastercontainer to disconnect the mastercontainer from the nextcloud-aio network.
4. now remove the nextcoud-aio network by running sudo docker network rm nextcloud-aio
5. Then run sudo docker network create nextcloud-aio in order to recreate the nextcloud-aio network
6. Finally run sudo docker network connect nextcloud-aio nextcloud-aio-mastercontainer to connect the mastercontainer to the network again.
7. At last, open the AIO interface and start your containers again
8. Now when failing a login, the correct remote ip-address should be logged.
9. If still not the correct ip-address should be logged, feel free to create a new discussion here: https://github.com/nextcloud/all-in-one/discussions/new?category=questions

[vijdz]

Even if I had strange ipv6 + docker behaviour (where docker is assigning local ipv6 to containers even though I asked it to disable ipv6 in daemon.json), this is not the reason why I saw wrong IP in the logs.

I followed your recommendations but then found out it does not work - my problem wasn't IPv6 but nginx reverse proxy (even though I'm using the default recommended config from this repo).
Since docker IP 172.18.0.1 was the one I saw in logs, I added it to conf.php "trusted_proxies" and now the right remote IP is shown.
May be you should edit the text here since there are many possible explanations other than ipv6 for this issue (mainly for reverse proxy config).

Cheers

[mio-19]

Yes, I am on Linux. I used the docker-compose.yml from https://github.com/nextcloud/all-in-one/tree/main/manual-install . The ip changed after docker compose down and docker compose up -d. Not sure if it is specific to manual-install.

I found 172.30 and docker0 in the output of ip a

5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:6a:d1:6c:1e brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:6aff:fed1:6c1e/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
135: br-78a6a413aeb1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:75:9a:98:68 brd ff:ff:ff:ff:ff:ff
    inet 172.30.0.1/16 brd 172.30.255.255 scope global br-78a6a413aeb1
       valid_lft forever preferred_lft forever
    inet6 fd12:3456:789a:2::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::42:75ff:fe9a:9868/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
    inet6 fe80::1/64 scope link
       valid_lft forever preferred_lft forever

Output of docker network inspect nextcloud-aio

[
    {
        "Name": "nextcloud-aio",
        "Id": "78a6a413aeb110b8c69bb6cab6d78c2621f031d8d0cfceb06a9bcfa2dc5a59b6",
        "Created": "2024-03-06T17:11:04.261401993+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": true,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "fd12:3456:789a:2::/64"
                },
                {
                    "Subnet": "172.30.0.0/16",
                    "Gateway": "172.30.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "0f1175b6c34a2785b3e31011f9b30bd5cac925044333df1e61f896c57ab48040": {
                "Name": "nextcloud-nextcloud-aio-apache-1",
                "EndpointID": "85b0436eaf55430ba7291c2413bd687c4d288a460bd9827c4e0225fd02b43c46",
                "MacAddress": "02:42:ac:1e:00:0a",
                "IPv4Address": "172.30.0.10/16",
                "IPv6Address": "fd12:3456:789a:2::a/64"
            },
            "6d85897dfcd70ba9153106340988d75a8ed4fdc046dc462e8e2802b79c86080a": {
                "Name": "nextcloud-nextcloud-aio-collabora-1",
                "EndpointID": "13f5591f81675971aaee37b3ae3917eec6bf432635ed6c1417bae618868a7105",
                "MacAddress": "02:42:ac:1e:00:05",
                "IPv4Address": "172.30.0.5/16",
                "IPv6Address": "fd12:3456:789a:2::5/64"
            },
            "751d7e6713638f21e56bd1901cb405cf87a5e513dbe9116cecf4fafa6b423f80": {
                "Name": "nextcloud-nextcloud-aio-redis-1",
                "EndpointID": "e7a25c7501254374eaf6374c4401b72584b8efa8e9508eb84badda3af8306940",
                "MacAddress": "02:42:ac:1e:00:08",
                "IPv4Address": "172.30.0.8/16",
                "IPv6Address": "fd12:3456:789a:2::8/64"
            },
            "9f830af646c5b533c61a4704f3d9db1754188c8cffee3a1847c3128aedfe0bc4": {
                "Name": "nextcloud-nextcloud-aio-talk-recording-1",
                "EndpointID": "3aae90a652d39901da9b3be58ca0fc7cc674843d54c7ab5402c2733ccf064151",
                "MacAddress": "02:42:ac:1e:00:06",
                "IPv4Address": "172.30.0.6/16",
                "IPv6Address": "fd12:3456:789a:2::6/64"
            },
            "a665269912fbb5a790c05c5b5d7645b6120c344e4704062789167c461e992733": {
                "Name": "nextcloud-nextcloud-aio-talk-1",
                "EndpointID": "544f99dc130b523c30d2066da3ca6ba6b1aa5ac810dd1920908b10b5231ca2f0",
                "MacAddress": "02:42:ac:1e:00:02",
                "IPv4Address": "172.30.0.2/16",
                "IPv6Address": "fd12:3456:789a:2::2/64"
            },
            "aeaf96954e55210481d8332903377b614dd804ce08714e3f7e28ec14e1b6cf89": {
                "Name": "nextcloud-nextcloud-aio-database-1",
                "EndpointID": "a33206a86ac34380dbcddff6606a0ce9eb93a3f8e2324cfc0737a0be5d198594",
                "MacAddress": "02:42:ac:1e:00:07",
                "IPv4Address": "172.30.0.7/16",
                "IPv6Address": "fd12:3456:789a:2::7/64"
            },
            "afb2a9268dffa883aa030cce83344a363ed82009cd8ce5f42031148b1270f589": {
                "Name": "nextcloud-nextcloud-aio-notify-push-1",
                "EndpointID": "a06c73f0ceb10f76d07334aa5ce0739415edfe44701ef16005a3dd9711a4b900",
                "MacAddress": "02:42:ac:1e:00:04",
                "IPv4Address": "172.30.0.4/16",
                "IPv6Address": "fd12:3456:789a:2::4/64"
            },
            "e10fa3ad7dcf902f530f4b1337051d569833a9d0a3f4762ff02a800bdec20ee0": {
                "Name": "nextcloud-nextcloud-aio-imaginary-1",
                "EndpointID": "dbb6f5ca21ae4da4ec9b70b3b8b55ae28939c294fb134f28f2828491eb37ab14",
                "MacAddress": "02:42:ac:1e:00:03",
                "IPv4Address": "172.30.0.3/16",
                "IPv6Address": "fd12:3456:789a:2::3/64"
            },
            "ea158c9e1415605b9b16d4f3d6caa2bfaa23b81dd5502918ff1fd30c23ba1bf9": {
                "Name": "nextcloud-nextcloud-aio-nextcloud-1",
                "EndpointID": "46259e8a579ed50891babd0c508c41c5df76e4dffe82d10bde8c1c8a2739e21c",
                "MacAddress": "02:42:ac:1e:00:09",
                "IPv4Address": "172.30.0.9/16",
                "IPv6Address": "fd12:3456:789a:2::9/64"
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "nextcloud-aio",
            "com.docker.compose.project": "nextcloud",
            "com.docker.compose.version": "2.24.6"
        }
    }
]

/cc @szaimen

[vijdz]

From what I see and what worked for me, adding 172.30.0.1 to trusted_proxies should work.
It has to be the IP address of the nextcloud-aio bridge, in your case it is the br-78a6a413aeb1 network interface.
This address should be the one you see in the logs.

If it changed from 172.25 to 172.30 it's probably because you reinitialized the AIO app (or major update maybe ?).

But this IP should stay the same because the nextcloud-aio bridge / network isn't deleted when for example you run docker compose down or a reboot.

[rowanmoul]

Actually docker compose does delete the network when you run down, so that would explain why the network ip range changed. If you want to update containers without taking everything down, add pull_policy: always to each service definition in the compose file. Then it will update and replace containers as needed whenever you run up.

[vijdz]

You're right !
But I'm almost sure this is not the case for me (but can't confirm this / down my NC right now), because I ran docker network create --driver bridge nextcloud-aio cmd myself, following those instructions when I was trying to enable ipv6.
So the network is most likely "external" since not defined in the yaml file.
As stated in the docs :

By default, the only things removed are:
- Containers for services defined in the Compose file.
- Networks defined in the networks section of the Compose file.
- The default network, if one is used.
Networks and volumes defined as external are never removed.

[rowanmoul]

In that case, it would persist yes. The only other thing you could do to be absolutely sure it kept the same subnet rage would be to specify the desired range when creating the network.

[rowanmoul]

I had to add the docker network gateway IP as a trusted proxy as shown in the OP with occ to get the correct IP address to show up in the logs. This really should be able to be set with an environment variable on the master container!
Using a caddy reverse proxy as shown here results in the docker gateway being the source IP for ALL requests unless it is designated as a trusted proxy! This is with docker's userland-proxy disabled too.

all-in-one/compose.yaml

Lines 40 to 50 in 5cbbe1b

	# caddy:
	# image: caddy:alpine
	# restart: always
	# container_name: caddy
	# volumes:
	# - ./Caddyfile:/etc/caddy/Caddyfile
	# - ./certs:/certs
	# - ./config:/config
	# - ./data:/data
	# - ./sites:/srv
	# network_mode: "host"

[ccaccb]

For those who are using docker rootless: the default rootless port driver doesn't forward remote IPs, so none of the above tipps will work. You need to switch to e.g. using slirp4netns also as a port driver. See #4621.

[regs01]

TrueNAS app.
2 => '172.16.0.0/12' is already in 'trusted_proxies', but still doesn't detect client ip.
Your remote address was identified as "172.16.1.X" and is not actively throttled at the moment.

[asavageiv]

I run Nextcloud behind multiple reverse proxies. One is on a VPS and another is in a separate container on the same machine as Nextcloud AIO but in the same Tailnet. I use split-dns to connect to the one on the same machine when I am connected to the Tailnet.

Both the VPS reverse proxy and the container reverse proxy may change their IP address. Can host names be used in the trusted_proxies list? E.g. my external reverse proxy is at "foo.example.com" and internal at "bar.example.com"?

[asavageiv]

Answered here: nextcloud/server#44495 (comment)

[arcimboldo]

I have the same issue. Running AIO within docker, on a machine with a dynamic IP and using dyndns, so I cannot put the public IP anywhere in the config.

I can see that the nextcloud instance receives packets with the correct HTTP_X_FORWARDED_FOR, and the originating IP is from the docker container running apache+caddy, and I can see that the IP of the apache container is within the range 172.18.0.0/16 which is listed in trusted_proxies in the config.php.

Failed logins are logged as if coming from the public IP matching the hostname of the instance.

I tried explicitly setting 'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'), in config.php and it seems to work, but I don't know if there is a way to persist this configuration setting.