The reverse proxy header configuration is incorrect. [ Kubernetes Bare Metal ]

I am running nextcloud container on kubernetes and I just can not fix Three warnings i get on warning page .

 The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy. If not, this is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. Further information can be found in the documentation.
    Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the documentation.
    Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the documentation.

The last two makes no sense for me. It complains of /.well-known/caldav and /.well-known/carddav, but if i try to get those address I see they are being correctly redirected to dav:

image

Concerning the “reverse proxy header”,

I tried to add the following to my config.php

    'trusted_proxies' =>
    array (
    0 => '10.233.90.131',
    1 => '127.0.0.1',
    2 => '10.233.96.141',
    ),
    'forwarded-for-headers' =>
    array (
    0 => 'X-Forwarded-For',
    1 => 'HTTP_X_FORWARDED_FOR'
    ),

where 10.233.90.131 and 10.233.96.141 are my nginx ingress ips.

But that does not fix it. I am out of ideas.

If i replace index.php for a very simple file like the one below, i can see all headers.

<?php
print_r($_SERVER);
?>

Array
(
    [HTTP_AUTHORIZATION] => 
    [htaccessWorking] => true
    [front_controller_active] => true
    [PATH_INFO] => 
    [HTTP_HOST] => snc.internal.lan
    [HTTP_X_REQUEST_ID] => ddefd30062b55007ef3c4765665969cc
    [HTTP_X_REAL_IP] => 10.27.252.1
    [HTTP_X_FORWARDED_FOR] => 10.27.252.1
    [HTTP_X_FORWARDED_HOST] => snc.internal.lan
    [HTTP_X_FORWARDED_PORT] => 443
    [HTTP_X_FORWARDED_PROTO] => https
    [HTTP_X_SCHEME] => https
    [HTTP_X_ORIGINAL_FORWARDED_FOR] => 10.27.252.1, 10.27.252.1
    [HTTP_USER_AGENT] => curl/7.58.0
   [HTTP_X_CLIENT_IP] => 10.27.252.1
    [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    [SERVER_SIGNATURE] => <address>Apache/2.4.38 (Debian) Server at snc.internal.lan Port 80</address>
    [SERVER_SOFTWARE] => Apache/2.4.38 (Debian)
    [SERVER_NAME] => snc.internal.lan
    [SERVER_ADDR] => 10.233.96.152
    [SERVER_PORT] => 80
    [REMOTE_ADDR] => 10.233.90.131
    [DOCUMENT_ROOT] => /var/www/html
    [REQUEST_SCHEME] => http
    [CONTEXT_PREFIX] => 
    [CONTEXT_DOCUMENT_ROOT] => /var/www/html
    [SERVER_ADMIN] => webmaster@localhost
    [SCRIPT_FILENAME] => /var/www/html/index.php
    [REMOTE_PORT] => 57024
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => 
    [REQUEST_URI] => /
    [SCRIPT_NAME] => /index.php
    [PHP_SELF] => /index.php
    [REQUEST_TIME_FLOAT] => 1586475103.394
    [REQUEST_TIME] => 1586475103
    [argv] => Array
        (
        )
    [argc] => 0
)

We can see that [REMOTE_ADDR] is set to the proxy IP as expected, but HTTP_X_REAL_IP, HTTP_X_FORWARDED_FOR and HTTP_X_CLIENT_IP all point to my real ip.

1 Like

Have you taken all the related steps in the documentation? It might help to see your vhost config.

https://docs.nextcloud.com/server/18/admin_manual/configuration_server/security_setup_warnings.html#your-web-server-is-not-set-up-properly-to-resolve-well-known-caldav-or-well-known-carddav

https://docs.nextcloud.com/server/18/admin_manual/configuration_server/reverse_proxy_configuration.html

Yes, i have checked, but still unable to make it work using the nginx ingress controller

@jsalatiel

In regards to the discovery issue I came across this that solved it for my kubernetes deployment;

As for the trusted proxy, I don’t know and it’s how I found your question. If you find a solution, let me know.

I have also found a fix for the proxy issue:

I created a new trusted proxy array in the config.php

'trusted_proxies' => 
array (
  0 => 'localhost',
  1 => '<kubernetes-deploymentapp-metadata-name>',
  2 => '<kubernetes-service-metadata-name>',
),
1 Like

Indeed, entering my proxy’s hostname (just proxy) fixed the warning. However, the docs specifically only mention:

  • IPv4 addresses,
    
  • IPv4 ranges in CIDR notation
    
  • IPv6 addresses
    

as valid array values. Whatever. This warning popped up out of nowhere anyway.