Forwarding client IP address using Nginx TLS reverse proxy - does AMP heed the headers?

2.7K Views
Last Post 25 August 2020
Topic Is Solved

AbhorrentJoel posted this 28 October 2019

OS/Release: Ubuntu 18.04.3 LTS

Product Name/Version: AMP V1.8.8.0

Problem Description: I had Nginx (1.14.0) setup through the AMP setup to provide a TLS reverse proxy, but it seems that with the generated configuration the client's IP address is not heeded by AMP and only returns 127.0.0.1 whenever accessed through the reverse proxy (this can be seen either in AMP's active sessions, by using "ampinstmgr View" or by viewing the logs).

Steps to reproduce:

Install AMP with Nginx and Certbot (automated within the getamp.sh script)
Login

Check the sessions in AMP or the logs once that is done and the client's IP address will be 127.0.0.1.

Actions taken to resolve so far: I don't remember every single change I have made, but I tried a few different combinations in the Nginx configuration including stuff like "setrealip_from" without success.

Here is an example of the config I have for the ADS instance in Nginx:

location / {
    proxy_pass              http://localhost:8080;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version      1.1;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";

    proxy_redirect          off;
    proxy_buffering         off;
    client_max_body_size    10240M;
}

Everything is untouched except for the WebSocket addition (the "upgrades") - everything other than that was generated, and even without that it was still not working.

So does AMP itself not heed forwarded IP addresses? Or is my Nginx configuration incorrect?

14 Comments

Order By: Standard | Newest | Votes

Admin

Mike posted this 28 October 2019

Is "UsingReverseProxy" set in AMPConfig.conf ?

AbhorrentJoel posted this 28 October 2019

The following value is set in the AMPConfig.conf:

Webserver.UsingReverseProxy=True

Admin

Mike posted this 28 October 2019

And is ReverseProxyHost set to 127.0.0.1? The Header AMP is looking for is "X-Forwarded-For".

AbhorrentJoel posted this 28 October 2019

The following value is set in the AMPConfig.conf:

Webserver.ReverseProxyHost=127.0.0.1

I honestly don't know if I have missed something or misconfigured something. If there are some other settings I should check, please list them so I can check over.

Admin

Mike posted this 28 October 2019

Try the next Nightly build (Or Bleeding Build if you have access to it), I've changed it to use the X-Real-IP header instead as that may be more appropriate.

AbhorrentJoel posted this 28 October 2019

A Patreon, Black, Platinum, Network Premium or Enterprise licence is required to use bleeding builds.

Oh no. Looks like I'm out of this one until the next Nightly. I have had licenses since the days of McMyAdmin but I guess I do not meet the criteria. :(

AbhorrentJoel posted this 29 October 2019 - Last edited 29 October 2019

Is this change incorporated into Nightly v20191029.1? It does not appear to work for me, so perhaps the issue may be on my side.

Configuration for Nginx proxy is as below:

#Generated by CubeCoders AMP for ADS
server {
    server_name [removed];

    location / {
        proxy_pass              http://127.0.0.1:8080;
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version      1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_redirect          off;
        proxy_buffering         off;
        client_max_body_size    10240M;
    }

    listen [::]:443 ssl http2 ipv6only=on; # managed by Certbot
    listen 443 ssl http2; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/[removed]/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/[removed]/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = [removed]) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name [removed];
    return 404; # managed by Certbot
}

I might need to setup a webpage using php to see if the header is indeed being passed correctly.

Admin

Mike posted this 29 October 2019

Where are you looking in AMP for the session IP?

AbhorrentJoel posted this 29 October 2019

In both "Active Sessions" and in the console for the instance (in this case, for ADS instance). I am running the Nightly v20191029.1 and this is what I get:

[16:50:30] [Auth:Anonymous Activity] : Authentication attempt for user [user] from 127.0.0.1

Here is config for the Security, Webserver and Login:

################################
# Security
################################
Security.ExecPath=Exec
Security.AllowConcurrentSessions=True
Security.LogAuthFailures=False
Security.AuthFailureLogPath=./AuthFailures.log
Security.LogSensitiveProcArgs=False
Security.EncIV=[removed]
Security.EnablePassthruAuth=True
# Security.PassthruAuthLocalOnly - Only allows auth requests that come from 127.0.0.1 - careful when using a controller that is bound to a specific IP rather than 0.0.0.0!
Security.PassthruAuthLocalOnly=False
Security.AuthFailureTimeWindow=5
Security.AuthFailureAttemptsInWindow=5
Security.TwoFactorMode=Optional
Security.AllowAPIDiscoveryWithoutLogin=False
Security.IgnoreAuthServerTLSFailure=False

################################
# Webserver
################################
# Webserver.Port - NEVER CHANGE THIS SETTING MANUALLY! Always use `ampinstmgr rebind` to alter IP/Port bindings. IF YOU CHANGE THIS ON ADS YOU WILL BREAK YOUR LOGINS!
Webserver.Port=8080
# Webserver.IPBinding - NEVER CHANGE THIS SETTING MANUALLY! Always use `ampinstmgr rebind` to alter IP/Port bindings. IF YOU CHANGE THIS ON ADS YOU WILL BREAK YOUR LOGINS!
Webserver.IPBinding=127.0.0.1
Webserver.SessionTimeout=5
Webserver.NoUI=False
Webserver.FilterEndpoints=False
Webserver.AllowedEndpointIPs=["127.0.0.1"]
Webserver.CertificatePath=
Webserver.CertificateSerial=
Webserver.CertificatePassword=
Webserver.EnableWebSockets=True
Webserver.EnablePluginWSStreams=False
Webserver.EnableFetchPostEndpoints=True
Webserver.APIRateLimit=100
Webserver.UsingReverseProxy=True
Webserver.ReverseProxyHost=127.0.0.1

################################
# Login
################################
Login.UseAuthServer=False
# Login.AuthServerURL - The URL for the ADS instance providing authentication when using UseAuthServer
Login.AuthServerURL=
Login.LDAPAllowAuthOnAnyDomain=False
Login.LDAPAuthDomain=

AbhorrentJoel posted this 29 October 2019 - Last edited 29 October 2019

I have just gone ahead and setup a webserver with php on my local machine and setup Nginx on my remote server to proxy to my local machine.

I have used the following script to check whether Nginx setup is forwarding the header correctly:

https://pastebin.com/y8fniZZJ (I had to pastebin because the formatting keeps getting messed up...)

The script returned my address in "X-Forwarded-For" and the "X-Real-IP" returned the address of the Nginx server that sent the request. This is, to my knowledge, working as intended.

I do not believe my setup to be at fault.

Admin

Mike posted this 29 October 2019

I'll check it out again then when I have a moment. :)

AbhorrentJoel posted this 31 October 2019 - Last edited 31 October 2019

I thought I'd give it a try and run a ADS instance on a local (Windows) PC and use my remote Nginx server as the reverse proxy just in case it was a Linux-specific AMP issue. I was running v1.8.8.0 and not FastTrack or Nightly release (I know you mentioned changing to X-Real-IP in Nightly, but it is X-Forwarded-For that has the client's IP address). In this case, the logs and Active Sessions reporting the IP address of the Nginx server.

AbhorrentJoel posted this 08 November 2019

I have done a fresh install of AMP 1.9.0.0, wiping all existing amp files (deleted the whole user), uninstalling Nginx and wiping all configs, and this still appears not to be working - all active sessions seem to originate from 127.0.0.1 still.

AbhorrentJoel posted this 25 August 2020

Since this has now been resolved as of AMP 2.0.5, I will now mark this as solved.

Forums Archived

Forwarding client IP address using Nginx TLS reverse proxy - does AMP heed the headers?

Categories

Search

Popular Tags

This Weeks High Earners

Hot Topics