[GH-ISSUE #2141] Access List not working! How can I setup NPM to protect certain subdomain for outside access? #1539

Closed
opened 2026-02-26 07:31:28 +03:00 by kerem · 17 comments
Owner

Originally created by @BobWs on GitHub (Jul 7, 2022).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2141

Hi,

I've setup NPM-Docker on my Synology NAS and when I try to setup Access List to protect certain sub.domains form outside access it doesn't work. See screenshot for my Access List setup and the proxy setup for subdomains.
Access-list
Access-list-setup
proxy-setup-subdomain

I have also tried to add a Custom Nginx Configuration to the Advanced Tab but that is also not working.

location /# {
  allow 192.168.178.0/24;
  deny all;
}

Advanced-settings

Any help please how to setup NPM with Access List protection to work properly.
TIA

Originally created by @BobWs on GitHub (Jul 7, 2022). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2141 Hi, I've setup NPM-Docker on my Synology NAS and when I try to setup Access List to protect certain sub.domains form outside access it doesn't work. See screenshot for my Access List setup and the proxy setup for subdomains. ![Access-list](https://user-images.githubusercontent.com/5485820/177742443-950ce94a-5e3f-4645-8bcc-36b1e6e97d41.png) ![Access-list-setup](https://user-images.githubusercontent.com/5485820/177742463-73bfba24-f99d-4126-b894-e5aabd786aa6.png) ![proxy-setup-subdomain](https://user-images.githubusercontent.com/5485820/177742478-9ef0dee6-f323-418c-804d-93b03f06674c.png) I have also tried to add a Custom Nginx Configuration to the Advanced Tab but that is also not working. ``` location /# { allow 192.168.178.0/24; deny all; } ``` ![Advanced-settings](https://user-images.githubusercontent.com/5485820/177743182-db29d725-33c7-4bd5-af77-3c596d61c6f0.png) Any help please how to setup NPM with Access List protection to work properly. TIA
kerem 2026-02-26 07:31:28 +03:00
  • closed this issue
  • added the
    stale
    bug
    labels
Author
Owner

@UrekD commented on GitHub (Jul 7, 2022):

I think you are missing a deny rule on your access list. This worked for me ex.
image

<!-- gh-comment-id:1178361849 --> @UrekD commented on GitHub (Jul 7, 2022): I think you are missing a deny rule on your access list. This worked for me ex. ![image](https://user-images.githubusercontent.com/38784343/177887231-a680d46c-1aea-4949-bfb2-2536afca69d4.png)
Author
Owner

@BobWs commented on GitHub (Jul 8, 2022):

I think you are missing a deny rule on your access list. This worked for me ex.

The deny rule is activated by default, but I could give it a try.

<!-- gh-comment-id:1178580652 --> @BobWs commented on GitHub (Jul 8, 2022): > I think you are missing a deny rule on your access list. This worked for me ex. The deny rule is activated by default, but I could give it a try.
Author
Owner

@UrekD commented on GitHub (Jul 8, 2022):

I think you are missing a deny rule on your access list. This worked for me ex.

The deny rule is activated by default, but I could give it a try.

I thought so myself, but it didn't work without it. Also check the console it could not like the networks you specified. You see in my screenshot I use large ranges because it wouldn't accept smaller /24 for some reason. It only shows error in the console.

Personally I'm planning to switch to standard nginx as this just breaks every so often, no fail2ban and other missing features.

<!-- gh-comment-id:1178955652 --> @UrekD commented on GitHub (Jul 8, 2022): > > I think you are missing a deny rule on your access list. This worked for me ex. > > The deny rule is activated by default, but I could give it a try. > > > I thought so myself, but it didn't work without it. Also check the console it could not like the networks you specified. You see in my screenshot I use large ranges because it wouldn't accept smaller /24 for some reason. It only shows error in the console. Personally I'm planning to switch to standard nginx as this just breaks every so often, no fail2ban and other missing features.
Author
Owner

@BobWs commented on GitHub (Jul 9, 2022):

thought so myself, but it didn't work without it.

Okay I will make the necessary changes and see if it works. Did you also enable Satisfy Any?

<!-- gh-comment-id:1179483158 --> @BobWs commented on GitHub (Jul 9, 2022): > thought so myself, but it didn't work without it. Okay I will make the necessary changes and see if it works. Did you also enable Satisfy Any?
Author
Owner

@UrekD commented on GitHub (Jul 9, 2022):

Okay I will make the necessary changes and see if it works. Did you also enable Satisfy Any?

No I did not. I checked and as you said the deny all doesn't matter not does Satisfy Any from what I can see, just the 2 rules do everything.

Eh it worked for 5 min... Satisfy on and 2 rules without the deny all works for now, removed and re added the rule.

<!-- gh-comment-id:1179622337 --> @UrekD commented on GitHub (Jul 9, 2022): > Okay I will make the necessary changes and see if it works. Did you also enable Satisfy Any? ~~No I did not. I checked and as you said the deny all doesn't matter not does Satisfy Any from what I can see, just the 2 rules do everything.~~ Eh it worked for 5 min... Satisfy on and 2 rules without the deny all works for now, removed and re added the rule.
Author
Owner

@BobWs commented on GitHub (Jul 11, 2022):

Okay I will make the necessary changes and see if it works. Did you also enable Satisfy Any?

No I did not. I checked and as you said the deny all doesn't matter not does Satisfy Any from what I can see, just the 2 rules do everything.

Eh it worked for 5 min... Satisfy on and 2 rules without the deny all works for now, removed and re added the rule.

So I have tried both ways, with and without the “extra deny rule” and they are both working.
For now I removed the extra rule and will see what happens overtime. Satisfy All is off.
I also checked the proxy hosts config files after removing the extra deny rule and I can confirm that the default rule is still present.

One thing I noticed is that you have to save all the proxy hosts again after editing the ACL.

<!-- gh-comment-id:1180024004 --> @BobWs commented on GitHub (Jul 11, 2022): > > Okay I will make the necessary changes and see if it works. Did you also enable Satisfy Any? > > ~No I did not. I checked and as you said the deny all doesn't matter not does Satisfy Any from what I can see, just the 2 rules do everything.~ > > Eh it worked for 5 min... Satisfy on and 2 rules without the deny all works for now, removed and re added the rule. So I have tried both ways, with and without the “extra deny rule” and they are both working. For now I removed the extra rule and will see what happens overtime. Satisfy All is off. I also checked the proxy hosts config files after removing the extra deny rule and I can confirm that the default rule is still present. One thing I noticed is that you have to save all the proxy hosts again after editing the ACL.
Author
Owner

@kingfisher77 commented on GitHub (Jul 15, 2022):

We experience also irritating problems with the access feature. We added some ip subnets with net masks and all of a sudden access ist not possible anymore. Browser reports "Your connection is not private”. Problem is, that also the nginx proxy admin interface is behind a secured subdomain and not accessible anymore.

It seems that nginx proxy manager is not matured... We just set it up like it is ment to.

<!-- gh-comment-id:1185859673 --> @kingfisher77 commented on GitHub (Jul 15, 2022): We experience also irritating problems with the access feature. We added some ip subnets with net masks and all of a sudden access ist not possible anymore. Browser reports "Your connection is not private”. Problem is, that also the nginx proxy admin interface is behind a secured subdomain and not accessible anymore. It seems that nginx proxy manager is not matured... We just set it up like it is ment to.
Author
Owner

@jmo161 commented on GitHub (Jul 20, 2022):

We experience also irritating problems with the access feature. We added some ip subnets with net masks and all of a sudden access ist not possible anymore. Browser reports "Your connection is not private”. Problem is, that also the nginx proxy admin interface is behind a secured subdomain and not accessible anymore.

It seems that nginx proxy manager is not matured... We just set it up like it is ment to.

After any changes to any access list, I've found that you need to edit the proxy configuration that uses that access list and re-save it (you don't need to make any changes) for it to un-break itself and take the modified access list.

I'm not sure if there's an issue for this specifically yet, if there isn't, we should create one as I do believe it to be a bug. It's pretty irritating when you have 30 proxy hosts sharing the same access list...

<!-- gh-comment-id:1190469556 --> @jmo161 commented on GitHub (Jul 20, 2022): > We experience also irritating problems with the access feature. We added some ip subnets with net masks and all of a sudden access ist not possible anymore. Browser reports "Your connection is not private”. Problem is, that also the nginx proxy admin interface is behind a secured subdomain and not accessible anymore. > > It seems that nginx proxy manager is not matured... We just set it up like it is ment to. After any changes to any access list, I've found that you need to edit the proxy configuration that uses that access list and re-save it (you don't need to make any changes) for it to un-break itself and take the modified access list. I'm not sure if there's an issue for this specifically yet, if there isn't, we should create one as I do believe it to be a bug. It's pretty irritating when you have 30 proxy hosts sharing the same access list...
Author
Owner

@kingfisher77 commented on GitHub (Jul 20, 2022):

True. Could you create a first version of the bug ticket as i am not so fluently with these kind of tasks. I would be delighted to finalize it together with you. Is this okay?

<!-- gh-comment-id:1190483101 --> @kingfisher77 commented on GitHub (Jul 20, 2022): True. Could you create a first version of the bug ticket as i am not so fluently with these kind of tasks. I would be delighted to finalize it together with you. Is this okay?
Author
Owner

@BobWs commented on GitHub (Jul 21, 2022):

After any changes to any access list, I've found that you need to edit the proxy configuration that uses that access list and re-save it (you don't need to make any changes) for it to un-break itself and take the modified access list.

That is the problem indeed I have noticed too. It’s very annoying if your proxy list is long!

<!-- gh-comment-id:1191069606 --> @BobWs commented on GitHub (Jul 21, 2022): > After any changes to any access list, I've found that you need to edit the proxy configuration that uses that access list and re-save it (you don't need to make any changes) for it to un-break itself and take the modified access list. That is the problem indeed I have noticed too. It’s very annoying if your proxy list is long!
Author
Owner

@talondnb commented on GitHub (Jul 23, 2022):

Yes, I have found this too. Any modification to access lists needs to be re-applied on the proxy hosts.

I have also found another issue; if you have custom advanced configuration that defines stuff within a 'location /', your access list on that proxy host is not actually applied to the proxy host .conf file!

e.g.
Screen Shot 2022-07-23 at 13 52 53

Screen Shot 2022-07-23 at 13 53 02

below conf with custom advanced config via gui, missing access list section (even after re-applying)

$ cat 14.conf 
# ------------------------------------------------------------
# blah.blah.blah
# ------------------------------------------------------------


server {
  set $forward_scheme http;
  set $server         "10.10.10.100";
  set $port           7878;

  listen 80;
#listen [::]:80;

listen 443 ssl http2;
#listen [::]:443;


  server_name blah.blah.blah;


  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /etc/letsencrypt/live/npm-7/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/npm-7/privkey.pem;






  # Block Exploits
  include conf.d/include/block-exploits.conf;







    # Force SSL
    include conf.d/include/force-ssl.conf;




proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;


  access_log /data/logs/proxy-host-14_access.log proxy;
  error_log /data/logs/proxy-host-14_error.log warn;

# Increase buffer size for large headers
# This is needed only if you get 'upstream sent too big header while reading response
# header from upstream' error when trying to access an application protected by goauthentik
proxy_buffers 8 16k;
proxy_buffer_size 32k;

location / {
    # Put your proxy_pass to your application here
    proxy_pass          $forward_scheme://$server:$port;

    # authentik-specific config
    auth_request        /outpost.goauthentik.io/auth/nginx;
    error_page          401 = @goauthentik_proxy_signin;
    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header Set-Cookie $auth_cookie;

    # translate headers from the outposts back to the actual upstream
    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
    auth_request_set $authentik_email $upstream_http_x_authentik_email;
    auth_request_set $authentik_name $upstream_http_x_authentik_name;
    auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

    proxy_set_header X-authentik-username $authentik_username;
    proxy_set_header X-authentik-groups $authentik_groups;
    proxy_set_header X-authentik-email $authentik_email;
    proxy_set_header X-authentik-name $authentik_name;
    proxy_set_header X-authentik-uid $authentik_uid;
}

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
    proxy_pass          http://10.10.10.100:9000/outpost.goauthentik.io;
    # ensure the host of this vserver matches your external URL you've configured
    # in authentik
    proxy_set_header    Host $host;
    proxy_set_header    X-Original-URL $scheme://$http_host$request_uri;
    add_header          Set-Cookie $auth_cookie;
    auth_request_set    $auth_cookie $upstream_http_set_cookie;
}

# Special location for when the /auth endpoint returns a 401,
# redirect to the /start URL which initiates SSO
location @goauthentik_proxy_signin {
    internal;
    add_header Set-Cookie $auth_cookie;
    return 302 /outpost.goauthentik.io/start?rd=$request_uri;
    # For domain level, use the below error_page to redirect to your authentik server with the full redirect path
    # return 302 https://authentik.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
}





  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}
<!-- gh-comment-id:1193067094 --> @talondnb commented on GitHub (Jul 23, 2022): Yes, I have found this too. Any modification to access lists needs to be re-applied on the proxy hosts. I have also found another issue; if you have custom advanced configuration that defines stuff within a 'location /', your access list on that proxy host is not actually applied to the proxy host .conf file! e.g. ![Screen Shot 2022-07-23 at 13 52 53](https://user-images.githubusercontent.com/3942363/180592457-06f6ab6b-6659-469a-86d5-55508a07241c.png) ![Screen Shot 2022-07-23 at 13 53 02](https://user-images.githubusercontent.com/3942363/180592459-8efafe8b-6b31-47e1-9720-648efa79ddf8.png) below conf with custom advanced config via gui, missing access list section (even after re-applying) ``` $ cat 14.conf # ------------------------------------------------------------ # blah.blah.blah # ------------------------------------------------------------ server { set $forward_scheme http; set $server "10.10.10.100"; set $port 7878; listen 80; #listen [::]:80; listen 443 ssl http2; #listen [::]:443; server_name blah.blah.blah; # Let's Encrypt SSL include conf.d/include/letsencrypt-acme-challenge.conf; include conf.d/include/ssl-ciphers.conf; ssl_certificate /etc/letsencrypt/live/npm-7/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/npm-7/privkey.pem; # Block Exploits include conf.d/include/block-exploits.conf; # Force SSL include conf.d/include/force-ssl.conf; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; access_log /data/logs/proxy-host-14_access.log proxy; error_log /data/logs/proxy-host-14_error.log warn; # Increase buffer size for large headers # This is needed only if you get 'upstream sent too big header while reading response # header from upstream' error when trying to access an application protected by goauthentik proxy_buffers 8 16k; proxy_buffer_size 32k; location / { # Put your proxy_pass to your application here proxy_pass $forward_scheme://$server:$port; # authentik-specific config auth_request /outpost.goauthentik.io/auth/nginx; error_page 401 = @goauthentik_proxy_signin; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; # translate headers from the outposts back to the actual upstream auth_request_set $authentik_username $upstream_http_x_authentik_username; auth_request_set $authentik_groups $upstream_http_x_authentik_groups; auth_request_set $authentik_email $upstream_http_x_authentik_email; auth_request_set $authentik_name $upstream_http_x_authentik_name; auth_request_set $authentik_uid $upstream_http_x_authentik_uid; proxy_set_header X-authentik-username $authentik_username; proxy_set_header X-authentik-groups $authentik_groups; proxy_set_header X-authentik-email $authentik_email; proxy_set_header X-authentik-name $authentik_name; proxy_set_header X-authentik-uid $authentik_uid; } # all requests to /outpost.goauthentik.io must be accessible without authentication location /outpost.goauthentik.io { proxy_pass http://10.10.10.100:9000/outpost.goauthentik.io; # ensure the host of this vserver matches your external URL you've configured # in authentik proxy_set_header Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; add_header Set-Cookie $auth_cookie; auth_request_set $auth_cookie $upstream_http_set_cookie; } # Special location for when the /auth endpoint returns a 401, # redirect to the /start URL which initiates SSO location @goauthentik_proxy_signin { internal; add_header Set-Cookie $auth_cookie; return 302 /outpost.goauthentik.io/start?rd=$request_uri; # For domain level, use the below error_page to redirect to your authentik server with the full redirect path # return 302 https://authentik.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri; } # Custom include /data/nginx/custom/server_proxy[.]conf; } ```
Author
Owner

@MrSmits commented on GitHub (Aug 30, 2022):

Check my comment on here, this workaround seems to work for me at least
https://github.com/NginxProxyManager/nginx-proxy-manager/issues/383#issuecomment-1231453474

<!-- gh-comment-id:1232077600 --> @MrSmits commented on GitHub (Aug 30, 2022): Check my comment on here, this workaround seems to work for me at least https://github.com/NginxProxyManager/nginx-proxy-manager/issues/383#issuecomment-1231453474
Author
Owner

@mgutt commented on GitHub (Nov 26, 2022):

alondnb

I can verify this behavior. Screenshots:
https://forums.unraid.net/topic/131150-nextcloud-benutzer-anlegen-klappt-nicht/?do=findComment&comment=1195344

A workaround is to add the code manually to the own location / block, but it will break if an access list is deleted.

<!-- gh-comment-id:1328061089 --> @mgutt commented on GitHub (Nov 26, 2022): > alondnb I can verify this behavior. Screenshots: https://forums.unraid.net/topic/131150-nextcloud-benutzer-anlegen-klappt-nicht/?do=findComment&comment=1195344 A workaround is to add the code manually to the own location / block, but it will break if an access list is deleted.
Author
Owner

@Vanillabacke commented on GitHub (Feb 27, 2023):

the access list has no effect on my server, which has the latest version installed ( v2.9.19 ).
tried all possible configurations / workarounds, what i have found. the login dialog won't show up.

<!-- gh-comment-id:1446605060 --> @Vanillabacke commented on GitHub (Feb 27, 2023): the access list has no effect on my server, which has the latest version installed ( v2.9.19 ). tried all possible configurations / workarounds, what i have found. the login dialog won't show up.
Author
Owner

@bbrfkr commented on GitHub (Mar 24, 2023):

+1

<!-- gh-comment-id:1482311313 --> @bbrfkr commented on GitHub (Mar 24, 2023): +1
Author
Owner

@github-actions[bot] commented on GitHub (Feb 14, 2024):

Issue is now considered stale. If you want to keep it open, please comment 👍

<!-- gh-comment-id:1942964691 --> @github-actions[bot] commented on GitHub (Feb 14, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:
Author
Owner

@github-actions[bot] commented on GitHub (Mar 30, 2025):

Issue was closed due to inactivity.

<!-- gh-comment-id:2764342968 --> @github-actions[bot] commented on GitHub (Mar 30, 2025): Issue was closed due to inactivity.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nginx-proxy-manager-NginxProxyManager#1539
No description provided.