All LAN ips are shown as the router/gateway - how can I get the actual IP address

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 23.0.2
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
Apache or nginx version (eg, Apache 2.4.25): 2.4.41
PHP version (eg, 7.4): 8.0

The issue you are facing:
Audit.log and nextcloud.log show the ip address of my router for every client that logs in from my lan. I would like themn to show the actual local ip address of the client. Note that the logs record the correct external IP when accessing from outside the LAN.

I worry that if someone enters a bad password from a LAN client, then all LAN clients will be throttled by brute force protection rather than just the one offending client.

Is this the first time you’ve seen this error? (Y/N):
N

Steps to replicate it:

  1. Log in to nextcloud from a client on the LAN
  2. Inspect the audit.log

The output of your Nextcloud log in Admin > Logging:

{"reqId":"z8ZF7tMy0Ddzh0BwvbFn","level":1,"time":"2022-03-02T14:25:18+00:00","remoteAddr":"192.168.1.254","user":"admin","app":"no app in context","method":"GET","url":"/index.php/settings/ajax/checksetup","message":"Deprecated event type for OCP\\IDBConnection::CHECK_MISSING_COLUMNS: Symfony\\Component\\EventDispatcher\\GenericEvent is used","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0","version":"23.0.2.1"}

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'stuff',
  'trusted_domains' =>
  array (
    0 => '192.168.1.19',
    1 => 'cloud.example.com',
    2 => 'cloud.lan.example.com',
  ),
  'passwordsalt' => 'stuffhere',
  'secret' => 'secretstuff',
  'datadirectory' => '/mnt/cloud/data',
  'dbtype' => 'mysql',
  'version' => '23.0.2.1',
  'overwrite.cli.url' => 'http://192.168.1.19',
  'dbname' => 'dbnamehere',
  'dbhost' => 'localhost:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'userhere',
  'dbpassword' => 'passwordhere',
  'installed' => true,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
  'updater.secret' => 'stuffhere',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 1,
  'trusted_proxies' =>
  array (
    1 => '127.0.0.1',
  ),
  'default_phone_region' => 'GB',
  'filelocking.enabled' => true,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '127.0.0.1',
    'port' => 6379,
  ),
  'overwriteprotocol' => 'https',
  'overwritehost' => 'cloud.example.com',
);

The output of your Apache/nginx/system log in /var/log/____:

192.168.1.254 - - [02/Mar/2022:14:34:03 +0000] "PUT /index.php/apps/user_status/heartbeat HTTP/1.1" 200 1326 "-" ">
192.168.1.254 - - [02/Mar/2022:14:34:05 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" >


It is because your domain bounded to the external IP address of your router and your Router could not route it “correctly” and make a loop:

some LAN Machine → Router → External IP of the Router → Router → Your server.

In this case you see IP of your router. You can try to add to /etc/hosts on a local machine IP address of your NC Server and FQDN and see if it is works now, e.g.:

192.168.1.19 cloud.example.com cloud.lan.example.com

What is your Router Model?

You can test if it is true with curl:

curl --resolve 'cloud.example.com:443:192.168.1.19' https://cloud.example.com

And check if this request was logged as “normal” LAN IP Address.

2 Likes

Hi @el_pedr0

As @gas85 already said. That’s beacuse cloud.example.com resolves to the WAN address of your router and your router then has to send the packets back to your server based on the DNAT (port forwading) rules. During this process the source IP of the packets gets rewritten. See here for a more detailed explanation: https://en.wikipedia.org/wiki/Network_address_translation#NAT_hairpinning

The best and most universal solution to bypass NAT loopback would be to set up a local DNS server, which resolves cloud.example.com to the local IP address of your server, instead of the WAN address. Then the requests will be sent directly to the the server and the packets will only hit the switch of your router. As a result, no source IP rewriting is happening and your server will see the actual IP address of the client that sent the request.

1 Like

Ah Ok. Arlighty -I’ve got an Asus AC68u running Merlin. I’ve now added dnsmasq entry in the router to point cloud.example.com to 192.168.1.19. Yay!!! I can now see the local IP address. Thank you.

However, I’ve also run the curl command from the cli of the nextcloud ubuntu machine and the response was:

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

I’m looking at that curl.haxx.se page now, but am a bit lost TBH. Does this message indicate something else might be wrong?

1 Like

I’m not sure. This response can mean multiple things. Are you using self signed certificates and / or a reverse proxy? In case you are using a reverse proxy, is DNS pointing to reverse proxy or directly to the Nextcloud server?

I’m using a let’s encrypt wildcard certificate for my domain.

The DNS record that I put on the router is pointing to the IP address of the nextcloud machine. That nextcloud machine runs the apache server and has nextcloud directly on that machine. So the apache config has a virtual host for the servername cloud.example.com which specifies the document root of nextcloud.

I think that means it’s not a reverse proxy, right? I’m new to webservers!

Yes. That’s right.

Not sure if it helps, but I would try to remove cloud.lan.example.com and '192.168.1.19' from the trusted domain array like this…

'trusted_domains' => 
  array (
    0 => 'cloud.example com',
  ),

…and change overwrite.cli.url to:

'overwrite.cli.url' => 'https://cloud.example.com',

After that you can remove 'overwritehost' => 'cloud.example.com', from the config.php. I don’t think that line is needed after you changed the overwrite.cli.url parameter to your domain name, or at least I don’t have it in my config and don’t have any issues.

Thanks @bb77. I’ve made those changes. No untoward effects, and quite happy now with what I think is quite a tidy config.

I still get the certificate warning when issuing that curl command, but I don’t experience any other problems, so I’m going to assume that everything is ok.

My initial problem with not seeing the LAN ips was resolved by the recommendations earlier in this thread. So marking this as solved. Thank you both.

2 Likes

Just to close this curl topic, if Certificate is self-signed or Curl has problems to check it but you want to check connectivity - simply add key -k to ignore certificate check.
Now you also want to see what is this certificate - add key -v to see more verbose information also come basic Certificate info. Together for your particular case could be:

curl -vk --resolve 'cloud.example.com:443:192.168.1.19' https://cloud.example.com

Curl output example you can find here with marked information about Certificate and TLS connection: