all works, but after success auth redirect to the proxy-host instead the public host

[lumpov]

Authelia works, first of all I open in browser https://ads.target.org, then redirected to https://auth.target.org/?rd=https%3A%2F%2Fads.target.org%2F

After authentication, I redirected to https://192.168.1.14:7100 - this is upstreamed proxy-host of ads.target.org.

If I disable all authelia - includes from ads.target.org the url works properly, no redirection to https://192.168.1.14:7100

The problem is in nginx. Please help.

Authelia v4.37.5 in docker

nginx on host system:

# nginx -v
nginx version: nginx/1.14.0 (Ubuntu)

/etc/nginx/sites-enabled/auth.target.org:

server {
    listen 443 ssl http2; # managed by Certbot

    server_name auth.target.org;

    set $upstream http://127.0.0.1:9091;

    location / {
        include /etc/nginx/snippets/proxy.conf;
        proxy_pass $upstream;
    }

    location /api/verify {
        proxy_pass $upstream;
    }

    ssl_certificate /etc/letsencrypt/live/auth.target.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/auth.target.org/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 {
    listen 80;

    server_name auth.target.org;

#    return 301 https://$host$request_uri;
    return 301 https://$server_name$request_uri;
}

/etc/nginx/sites-enabled/ads.target.org:

server {
    listen 443 ssl http2; # managed by Certbot

    server_name ads.target.org;

    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    include /etc/nginx/snippets/authelia-location.conf;

    location / {
	include /etc/nginx/snippets/proxy.conf;
	include /etc/nginx/snippets/authelia-authrequest.conf;

	proxy_pass http://192.168.1.14:7100/;
    }

    ssl_certificate /etc/letsencrypt/live/ads.target.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/ads.target.org/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = ads.target.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name ads.target.org;

    listen 80;
    return 404; # managed by Certbot
}

authelia-authrequest.conf:

## Send a subrequest to Authelia to verify if the user is authenticated and has permission to access the resource.
auth_request /authelia;

## Set the $target_url variable based on the original request.

## Comment this line if you're using nginx without the http_set_misc module.
#set_escape_uri $target_url $scheme://$http_host$request_uri;

## Uncomment this line if you're using NGINX without the http_set_misc module.
set $target_url $scheme://$http_host$request_uri;

## Save the upstream response headers from Authelia to variables.
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
auth_request_set $name $upstream_http_remote_name;
auth_request_set $email $upstream_http_remote_email;

## Inject the response headers from the variables into the request made to the backend.
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
proxy_set_header Remote-Name $name;
proxy_set_header Remote-Email $email;

## If the subreqest returns 200 pass to the backend, if the subrequest returns 401 redirect to the portal.
error_page 401 =302 https://auth.target.org/?rd=$target_url;

authelia-location.conf:

location /authelia {
    ## Essential Proxy Configuration
    internal;
    proxy_pass $upstream_authelia;

    ## Headers
    ## The headers starting with X-* are required.
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_set_header X-Original-Method $request_method;
    proxy_set_header X-Forwarded-Method $request_method;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-Uri $request_uri;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Content-Length "";
    proxy_set_header Connection "";

    ## Basic Proxy Configuration
    proxy_pass_request_body off;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; # Timeout if the real server is dead
    proxy_redirect http:// $scheme://;
    proxy_http_version 1.1;
    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;
    proxy_buffers 4 32k;
    client_body_buffer_size 128k;

    ## Advanced Proxy Configuration
    send_timeout 5m;
    proxy_read_timeout 240;
    proxy_send_timeout 240;
    proxy_connect_timeout 240;
}

proxy.conf:

## Headers
proxy_set_header Host $host;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Uri $request_uri;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Connection "";

## Basic Proxy Configuration
client_body_buffer_size 128k;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; ## Timeout if the real server is dead.
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 64 256k;

## Trusted Proxies Configuration
## Please read the following documentation before configuring this:
##     https://www.authelia.com/integration/proxies/nginx/#trusted-proxies
# set_real_ip_from 10.0.0.0/8;
# set_real_ip_from 172.16.0.0/12;
# set_real_ip_from 192.168.0.0/16;
# set_real_ip_from fc00::/7;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

## Advanced Proxy Configuration
send_timeout 5m;
proxy_read_timeout 360;
proxy_send_timeout 360;
proxy_connect_timeout 360;

[james-d-elliott]

This appears like the service itself is redirecting you. Can you show logs and confirm the behaviour without authelia is the same/different?

[lumpov]

(thank you for your answer)

ads.target.org without Authelia works properly. No browser redirect to upstream proxy.

log (404 - is the mask of the public IP):

$ docker logs authelia
time="2023-02-10T15:00:30Z" level=info msg="Authelia v4.37.5 is starting"
time="2023-02-10T15:00:30Z" level=info msg="Log severity set to debug"
time="2023-02-10T15:00:30Z" level=info msg="Storage schema is being checked for updates"
time="2023-02-10T15:00:30Z" level=info msg="Storage schema is already up to date"
time="2023-02-10T15:00:30Z" level=debug msg="The NTP startup check was skipped due to there being no configured 2FA access control rules"
time="2023-02-10T15:00:30Z" level=debug msg="Directory is being watched for changes to the file" directory=/config file=users_database.yml
time="2023-02-10T15:00:31Z" level=info msg="Initializing server for non-TLS connections on '[::]:9091' path '/'"
addme@devops:~/dock/authelia$ docker logs authelia
time="2023-02-10T15:00:30Z" level=info msg="Authelia v4.37.5 is starting"
time="2023-02-10T15:00:30Z" level=info msg="Log severity set to debug"
time="2023-02-10T15:00:30Z" level=info msg="Storage schema is being checked for updates"
time="2023-02-10T15:00:30Z" level=info msg="Storage schema is already up to date"
time="2023-02-10T15:00:30Z" level=debug msg="The NTP startup check was skipped due to there being no configured 2FA access control rules"
time="2023-02-10T15:00:30Z" level=debug msg="Directory is being watched for changes to the file" directory=/config file=users_database.yml
time="2023-02-10T15:00:31Z" level=info msg="Initializing server for non-TLS connections on '[::]:9091' path '/'"
time="2023-02-10T15:01:05Z" level=debug msg="Check authorization of subject username= groups= ip=404.404.404.404 and object https://ads.target.org/ (method GET)."
time="2023-02-10T15:01:05Z" level=info msg="Access to https://ads.target.org/ (method GET) is not authorized to user <anonymous>, responding with status code 401" method=GET path=/api/verify remote_ip=404.404.404.404
time="2023-02-10T15:01:25Z" level=debug msg="Mark 1FA authentication attempt made by user 'john'" method=POST path=/api/firstfactor remote_ip=404.404.404.404
time="2023-02-10T15:01:25Z" level=debug msg="Successful 1FA authentication attempt made by user 'john'" method=POST path=/api/firstfactor remote_ip=404.404.404.404
time="2023-02-10T15:01:25Z" level=debug msg="Check authorization of subject username=john groups=admins,dev ip=404.404.404.404 and object https://ads.target.org/ (method )."
time="2023-02-10T15:01:25Z" level=debug msg="Required level for the URL https://ads.target.org/ is 1" method=POST path=/api/firstfactor remote_ip=404.404.404.404
time="2023-02-10T15:01:25Z" level=debug msg="Redirection URL https://ads.target.org/ is safe" method=POST path=/api/firstfactor remote_ip=404.404.404.404
time="2023-02-10T15:01:26Z" level=debug msg="Check authorization of subject username=john groups=admins,dev ip=404.404.404.404 and object https://ads.target.org/ (method GET)."

[james-d-elliott]

Can you find the request in your browsers network tab which makes the redirect it'll have a 30x code and a location response header. We have no information on that backend IP so I'm not sure how we'd redirect there.

[lumpov]

The problem is in your proxy.conf described in https://www.authelia.com/integration/proxies/nginx/#proxyconf

proxy_redirect  http://  $scheme://;

Also in https://www.authelia.com/integration/proxies/nginx/#authelia-locationconf the same proxy_redirect.

This setting pass redirects with absolute (local) url from app behind proxy. Disable this setting solve the problem. Redirection from http -> https made in first level of nginx site conf.

[james-d-elliott]

That's very unlikely to be the actual issue. This is tested in integration testing and has existed in the docs for literal years with zero other users reporting this issue.

[james-d-elliott]

See here for the users workaround for a an application that sends redirects inappropriately.

See here for what this directive does: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect

The way Authelia has this configured prevents redirections to the http scheme only. This is a workaround for applications which don't respect the X-Forwarded-Proto header when redirecting.

The appropriate solutions are:

1. Always use a supported version of your proxy. The proxy in this issue has been end of life and unsupported by F5 for 4 years.
2. Have the application in question properly redirect users.
3. Seek the documentation of the application in question for how to configure the proxy you're using in a particular scenario.

Workarounds:

1. User has a suggested workaround for NGINX linked in this post.

So if 192.168.1.14:7100 is returning a Location redirect to http://192.168.1.14:7100/a/path erroneously this would instead cause nginx to redirect to https://192.168.1.14:7100/a/path. But that would indicate a bug or specific proxy configuration need with 192.168.1.14:7100 when it's redirecting inappropriately.