CGI REMOTE_ADDR & Bad url

[DanielB1990]

Hello!

First of all, thanks for packaging this great piece of software and adding more features to it! I'm trying to use 'tiredofit/lemonldap:2.0_alpine-1.9.6' in my Caprover swarm, which uses nginx to reverse proxy.

So for so good, manager is reachable, I can login and all, but I seem to have 2 problems that I can't pin-point to being in the 'base' of lemonldap-ng or in the modifications/features you're adding.

The problem I have are:

• Bad URL ( Reaching https://test.sso.example.nl for the first time )
• Login History shows "10.0.0.5", which correlates with "REMOTE_ADDR" on https://test.sso.example.nl below "Environment for Perl CGI".

The values for "HTTP_X_FORWARDED_FOR", "HTTP_X_REAL_IP" are set correctly, to my IP.

So I've been through both https://lemonldap-ng.org/documentation/2.0/behindproxyminihowto.html#http-header and https://lemonldap-ng.org/documentation/2.0/behindproxyminihowto.html#fixing-handler-redirections and those seem to be corrected here:

/etc/cont-init.d/10-nginx:  sed -i "s#<REAL_IP_HEADER>#${NGINX_REAL_IP_HEADER}#g" /etc/nginx/nginx.conf.d/reverse_proxy.conf
/etc/cont-init.d/10-nginx:  sed -i "s#<SET_REAL_IP_FROM>#${NGINX_SET_REAL_IP_FROM}#g" /etc/nginx/nginx.conf.d/reverse_proxy.conf
/etc/cont-init.d/10-nginx:  sed -i "\#include /etc/nginx/nginx.conf.d/reverse_proxy.conf;#d" /etc/nginx/nginx.conf

---

cat /etc/nginx/nginx.conf.d/reverse_proxy.conf
    real_ip_header X-Forwarded-For;
    set_real_ip_from 172.16.0.0/12;

And in /etc/nginx/fastcgi_params by the /etc/cont-init.d/10-nginx part, so my guess is, that it could be caused by:

nginx (caprover) > nginx ( tiredofit/lemonldap:2.0_alpine-1.9.6 container ) > llng-fastcgi-server

But am unsure how to handle this, would you have any guidance on this? Or would I need to reach out to lemonldap-ng themselves?

[tiredofit]

Hi there thanks for compliments. Main LLNG developers won't be of much help and I'm pretty careful to jump on the list and steer people over to me should there be image issues which is what this seems to be. It sounds like you have everything setup correctly (I too have used Nginx as a Reverse Proxy in the past for 3 years with great success.

One thing I want to make sure and my apologies that these are basic:

a) You have created proper CNAME/A records for the various hosts (portal, manager, test) b) Have you tried accessing those sites from another site other than your own? You could be hitting some strange NAT loopback which is not forwarding your IP properly.

Let me know and we'll work on getting them sorted out if I can.

[DanielB1990]

Hi!

A) Yes, and A with wildcards to cover the subdomains ( multi-level ) B) I've asked my colleague to check, which also gets the same results.

This is what happens via cURL & Browser. I reckon it's the double redirect with "?url=" and/or the http <> https that is the problem.

I've decoded the base64 string behind "?url=" and added it below in between ( ... ) :

Going to: https://test.sso.toolit.nl

curl -IL https://test.sso.toolit.nl
HTTP/2 302
server: nginx
date: Fri, 19 Mar 2021 07:45:24 GMT
content-type: text/html
content-length: 145
location: http://auth.sso.toolit.nl/?url=aHR0cDovL3Rlc3Quc3NvLnRvb2xpdC5ubC8%3D ( http://test.sso.toolit.nl/7 )

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 19 Mar 2021 07:45:24 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Location: https://auth.sso.toolit.nl/?url=aHR0cDovL3Rlc3Quc3NvLnRvb2xpdC5ubC8%3D?url=aHR0cDovL3Rlc3Quc3NvLnRvb2xpdC5ubC8%3D ( 1: http://test.sso.toolit.nl/7 ) ( 2: http://test.sso.toolit.nl/7 )

HTTP/2 400
server: nginx
date: Fri, 19 Mar 2021 07:45:24 GMT
content-type: text/html; charset=utf-8
content-length: 328
access-control-allow-origin: *
access-control-allow-credentials: true
access-control-allow-headers: *
access-control-allow-methods: POST,GET
access-control-expose-headers: *
access-control-max-age: 86400

Going to: http://test.sso.toolit.nl

curl -IL http://test.sso.toolit.nl
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 19 Mar 2021 07:52:21 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Location: https://test.sso.toolit.nl/

HTTP/2 302
server: nginx
date: Fri, 19 Mar 2021 07:52:21 GMT
content-type: text/html
content-length: 145
location: http://auth.sso.toolit.nl/?url=aHR0cDovL3Rlc3Quc3NvLnRvb2xpdC5ubC8%3D ( http://test.sso.toolit.nl/7 )

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 19 Mar 2021 07:52:21 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Location: https://auth.sso.toolit.nl/?url=aHR0cDovL3Rlc3Quc3NvLnRvb2xpdC5ubC8%3D?url=aHR0cDovL3Rlc3Quc3NvLnRvb2xpdC5ubC8%3D ( 1: http://test.sso.toolit.nl/7 ) ( 2: http://test.sso.toolit.nl/7 )

HTTP/2 400
server: nginx
date: Fri, 19 Mar 2021 07:52:22 GMT
content-type: text/html; charset=utf-8
content-length: 328
access-control-allow-origin: *
access-control-allow-credentials: true
access-control-allow-headers: *
access-control-allow-methods: POST,GET
access-control-expose-headers: *
access-control-max-age: 86400

[tiredofit]

Whats your Portal URL set to? Check to make sure it says https://.. not http:// (default) (General -> Portal -> URL) Also lets try to make sure your Cookies are secure (General -> Cookies -> Secured Cookie (SSL) -> Secured Cookies (SSL)

Something is reminding me of similar issues in the past.

[DanielB1990]

I've checked the URL's and those were set to http:// and now changed to https:// as well as setting cookies to secure. That fixed the Bad URL, thanks!

Any idea on the "10.0.0.5"?

[tiredofit]

Sadly no. I can't recreate that on my end. What I would like to do is put some time in the near future on the parent image (tiredofit/nginx) and enable functionality to move to "proxy" protocol as opposed to these header hacks. If you wanted to try that ahead of time with changing the running config that would be helpful to let me know if it resolved it. Main Nginx configuration is here: /etc/nginx/nginx.conf and of course the LLNG stuff /etc/nginx/conf.d/ - nginx -s reload should do a live configuration reload without having to restart the container.

Without having to hack away - there's also something you can try, is with the Vhost settings inside manager for your Portal URL and trying to change the settings for HTTPS from Default to On or Off. Take a backup of your config file ahead of time or just delete the new config that was saved in the filesystem to get things working again if it breaks.

[DanielB1990]

After getting in contact with the LemonLDAP community mailing list, my brain/thoughts were reset.

I needed to change/set "REAL_IP" var in /etc/nginx/nginx.conf.d/reverse_proxy.conf correctly.

This could also be done via env variable NGINX_SET_REAL_IP_FROM.

From the official documentation I needed to set it to 127.0.0.1, but in my case changing it to 10.0.0.5 resulted in showing the right REMOTE_ADDR.

So for those looking here with the same problem, set the 'Last login' IP Address as NGINX_SET_REAL_IP_FROM.

Considered resolved.