All requests originate from 172.19.0.X

Nextcloud version 13:
Operating system and version Debian 9:
Apache or nginx version Docker / nginx proxy / apache:

The issue you are facing:

All requests originate from 172.19.0.2 instead of the incoming IP. The main undesirable side effect is that failed login attempts are all attributed to the same IP regardless of their actual origin, causing login/uploading one image has an added delay of about ~30 seconds.

Is this the first time you've seen this error? N:

Steps to replicate it:

git clone https://github.com/nextcloud/docker
cd .examples/docker-compose/with-nginx-proxy/postgres/apache
sudo docker-compose up -d

From Admin > Logging:

Warning | core | Login failed: 'Max' (Remote IP: '172.19.0.2') | 2018-03-25T23:47:30+0200

From the server logs:

$ cd docker/.examples/docker-compose/with-nginx-proxy/postgres/apache
$ sudo docker-compose logs proxy
...
proxy_1                  | nginx.1    | a.b.org 86.288.202.127 - - [25/Mar/2018:12:11:25 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/2.0" 200 74 "-""Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0"
$ sudo docker-compose logs app
...
app_1                    | 172.19.0.2 - - [26/Mar/2018:06:56:56 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 200 689 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0"

I've got almost the same issue before.

This is due to a security check, NC can't tell if it's true when a same IP says it's a rev-proxy, and keeps login on behalf of someone unlimited.

The solution must match with the rev proxy setup, and I handled it this way:

nginx on host, listen on 80/443
start container with docker compose, with a separate network 172.32.0.0/24
setup compose to build custom image from NC, add a bunch of config php file with one containing

<?php
$CONFIG = array (
'trusted_proxies' => array(
'172.32.0.1',
),
);

as docker put host as nat gateway on 172.32.0.1

And for your issue, with a container as nginx proxy:

use separate network
assign static ip for nginx in compose config
replace ip in php config

We solve it at the nginx level:

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
...
        set_real_ip_from  172.0.0.0/8;
        real_ip_header X-Forwarded-For;
...

But this is difficult to fix it for everybody as this address depends on your setup.
I hope that by moving to k8s we'll find a nicer workaround.

@pierreozoux

we could simply allow any rfc1918 address

set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
set_real_ip_from 192.168.0.0/16;
real_ip_header X-Forwarded-For

this should fix it for most people

@pierreozoux are you sure that ngx_http_realip_module is part of the nginx image?

@tilosp

Good idea @tilosp :)

Yes, for the debian and alpine version \o/

$ docker run -it nginx nginx -V                                                                                                                                                          
nginx version: nginx/1.13.10
built by gcc 6.3.0 20170516 (Debian 6.3.0-18) 
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.13.10/debian/debuild-base/nginx-1.13.10=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'
$ docker run -it nginx:alpine nginx -V                                                                                                                                                          
nginx version: nginx/1.13.10
built by gcc 6.4.0 (Alpine 6.4.0) 
built with OpenSSL 1.0.2n  7 Dec 2017
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-threads --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-stream_geoip_module=dynamic --with-http_slice_module --with-mail --with-mail_ssl_module --with-compat --with-file-aio --with-http_v2_module

@dachary

@dachary Still not sure..
Solved with:

apt-get install libapache2-mod-rpaf

/etc/apache2/mods-available/rpaf.conf
<IfModule rpaf_module>
    RPAFenable On
    RPAFsethostname On
    RPAFheader X-Real-IP
    RPAFproxy_ips 172.17.0.10
</IfModule>

(thanks to: https://www.daveperrett.com/articles/2009/08/10/passing-ips-to-apache-with-nginx-proxy/)

a2enmod rpaf

docker restart nextcloud

Now proper ips show up

I had to apply this patch manually to the insecure docker examples. Any reason why those were excluded ? I use the insecure docker image with a host nginx reverse proxy. So it still affects that.

Not sure this should be closed. There is more than just using mod_remoteip that needs changing. I am using the 14.0 image, and on that platform, you ALSO need to change the LogFormat directive in apache2.conf to use the %a variable instead of the %h variable to log to proper client IPs.

@bfayers

I have the same setup as @bfayers and also having the same issue. In the past I had used mod_rpaf in Apache to get actual client addresses. It seems there should be more than just mod_remoteip configuration. Can anybody fix this in Nextcloud Docker image?

#294 (comment)
Fixes it for me as well. Would be nice to have it in the official image

@bfayers

@bfayers Do you mind sharing your whole config? I'm using the jwilder proxy as well, but nextcloud.log still shows private IPs.

Edit: Nvm, got it working. I had multiple Forwarded-For Headers in my config, which apparently breaks this function.

Is there something additional to do if someone uses an apache2 reverse proxy in front of the nextcloud docker - apache2 image? It just doesnt work for me. :(

For my knowledge mod_proxy / mod_proxy_http should add the needed headers (X-Forwarded-For) automatically. But in the docker logs it shows still the gateway address of the docker network. Any ideas?

I am facing the same issue with not seeing the visitors ip in the nextcloud container behind a reverse proxy container. My solution used to be to run the reverseproxy with --net=host and to add the header to the logsettings for the virtual host. Docker bridge networking does not pass the headers through.

Why is this ticket closed? The nc images still have this bug. Bruteforce detection does not work when using docker in regular way.

From the docs: https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/reverse_proxy_configuration.html

'trusted_proxies' => array('172.xx.0.x'),
'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'),

Solved it for me

I did some digging on this issue. The reasons why it appears to be not working.

docker logs don't show the correct client ip. This is because the log format needs to be changed. However since there is a proxy already, you can rely on its log instead of docker logs which is recorded by the apache. Note that the nextcloud logs does have the correct client ip.
If you are testing it from an internal ip (e.g. 192.168..) , it won't work. For this to work, the conf should use a different directive. https://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipinternalproxy

Solution:
Use the 'trusted_proxies' config option to specify directly in nextcloud.
https://gitlab.com/snippets/1884088

On a side note, I recommend configuring overwriteprotocol to https. Without this the file share links generated are http ones and thus can be trapped.

@tilosp

I simply added 172.0.0.0/8 to trusted_proxies, and it worked, since my reverse proxy is on another docker container.

EDIT: Never mind, the IPs in the logs still show the local nginx reverse proxy container's 172.8.x.x. IP. But adding @tilosp's lines worked.

You need to disable the Docker Userland proxy to get the real client IP. Otherwise all requests will originate from the gateway.

If you are testing it from an internal ip (e.g. 192.168..) , it won't work. For this to work, the conf should use a different directive. https://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipinternalproxy

For anyone experiencing the same problem, try to access Nextcloud with your phone over mobile internet; the remote IP showed up correctly. Had been scratching my head for over an hour why I couldn't see my real (internal) IP address, but #294 (comment) was right on point.

Navigation Menu

Repository navigation

All requests originate from 172.19.0.X #294

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

All requests originate from 172.19.0.X #294

Description

Activity

chm commented on Mar 27, 2018

pierreozoux commented on Mar 27, 2018

tilosp commented on Mar 27, 2018

pierreozoux commented on Mar 27, 2018

7 remaining items

bfayers commented on Apr 15, 2018

pgera commented on Oct 3, 2018

mossholderm commented on Oct 4, 2018

nightspotlight commented on Nov 18, 2018

bonanza123 commented on Dec 25, 2018

DatAres37 commented on Jan 10, 2019

TheReal1604 commented on Jan 16, 2019

cs33lm commented on Jan 17, 2019

godfuture commented on Mar 13, 2019

robfuscator commented on Apr 25, 2019

balki commented on Aug 9, 2019

melyux commented on Sep 14, 2019

SuperSandro2000 commented on Jun 1, 2020

woutergrimme commented on Apr 20, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions