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

  • 67 Views
  • Last Post 2 weeks ago
AbhorrentJoel posted this 3 weeks ago

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?

Order By: Standard | Newest | Votes
Mike posted this 3 weeks ago

Is "UsingReverseProxy" set in AMPConfig.conf ?

AbhorrentJoel posted this 3 weeks ago

The following value is set in the AMPConfig.conf:

Webserver.UsingReverseProxy=True

Mike posted this 3 weeks ago

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

AbhorrentJoel posted this 3 weeks ago

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.

Mike posted this 3 weeks ago

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 3 weeks ago

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 3 weeks ago

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.

Mike posted this 3 weeks ago

Where are you looking in AMP for the session IP?

AbhorrentJoel posted this 3 weeks ago

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 3 weeks ago

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.

Mike posted this 3 weeks ago

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

AbhorrentJoel posted this 3 weeks ago

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 2 weeks ago

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.

Close