[GH-ISSUE #615] IP Allow List / CloudFlare Trusted IPs

kerem commented

2026-02-26 06:33:13 +03:00

Owner

Originally created by @rapidbnnuy on GitHub (Sep 25, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/615

Is your feature request related to a problem? Please describe.
There is no way to add more than 4 ranges in the IP Allow List on Access Lists. There needs to be a button to add additional ranges.

Describe the solution you'd like
There needs to be an additional button to add additional IP ranges similar to how there is a button to add locations on a Proxy Host. To continue with CloudFlare support, it would be fantastic if someone added a button to automatically setup trusted ranges for CloudFlare. They could be dynamically queried from the URL, https://www.cloudflare.com/ips-v4.

Describe alternatives you've considered
I've considered creating a dockerfile and pushing IPTABLES to the container, but that doesn't seem like the cleanest solution, and I'm not sure it would even work. I'm trying to run the container on Windows, so I don't have access to native IPTABLES rules to make this happen. I'm not looking for nginx-proxy-manager to turn into a firewall, but quickly being able to lock it down to only talk with CloudFlare, would be a great security feature.

Originally created by @rapidbnnuy on GitHub (Sep 25, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/615 **Is your feature request related to a problem? Please describe.** There is no way to add more than 4 ranges in the IP Allow List on Access Lists. There needs to be a button to add additional ranges. **Describe the solution you'd like** There needs to be an additional button to add additional IP ranges similar to how there is a button to add locations on a Proxy Host. To continue with CloudFlare support, it would be fantastic if someone added a button to automatically setup trusted ranges for CloudFlare. They could be dynamically queried from the URL, https://www.cloudflare.com/ips-v4. **Describe alternatives you've considered** I've considered creating a dockerfile and pushing IPTABLES to the container, but that doesn't seem like the cleanest solution, and I'm not sure it would even work. I'm trying to run the container on Windows, so I don't have access to native IPTABLES rules to make this happen. I'm not looking for nginx-proxy-manager to turn into a firewall, but quickly being able to lock it down to only talk with CloudFlare, would be a great security feature.

kerem

2026-02-26 06:33:13 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@Kipjr commented on GitHub (Oct 3, 2020):

Creating a host and an access list wont work? Why is that not a solution?

@Kipjr commented on GitHub (Oct 3, 2020): Creating a host and an access list wont work? Why is that not a solution? ![image](https://user-images.githubusercontent.com/12066560/94989958-d6a0aa00-0578-11eb-8f3c-82a781bc7587.png) ![image](https://user-images.githubusercontent.com/12066560/94989946-a822cf00-0578-11eb-8833-63ced4c94491.png)

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@rapidbnnuy commented on GitHub (Oct 3, 2020):

Because for some reason, the access list is limited to 4 host entries, and does not support comma separated lists. You can only specify a maximum of 4 ranges, and as you can see from the link, Cloudflare has more than that.

@rapidbnnuy commented on GitHub (Oct 3, 2020): Because for some reason, the access list is limited to 4 host entries, and does not support comma separated lists. You can only specify a maximum of 4 ranges, and as you can see from the link, Cloudflare has more than that.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@rapidbnnuy commented on GitHub (Oct 11, 2020):

I'm really combining two separate issues here, but allow me to explain further. My goal as an End User is to configured nginx-proxy-manager with full protection behind Cloudflare. That may be an edge case, and some or all of the requested features may not warrant implementation for what nginx-proxy-manager is looking to provide. However, from past posts I have identified support for trying to make this happen, so I felt like opening this issue would be worthwhile as an enhancement request. Cloudflare offers maximum protection when the destination web server is configured for HSTS with Preload, TLS 1.3, HTTP/2 (or 3), Configured for IP Allow for Cloudflare IPv4 ranges, and Deny All for all other traffic, and SSL Certificate Pinning with Cloudflare's generated Origin CA Certificate. There are further features, but that's enough to protect your IP address or web server from being exposed to the Internet without going through Cloudflare.

HSTS with Preload is currently in the build and working, as is HTTP/2 and TLS 1.3 with Wildcard SSL Certificate with automatic DNS verification with Cloudflare. That's significant. However, I have been unable to locate any assistance for how to configure the Origin CA Certificate or the IP Allow Ranges. Upon attempting to configure the IP Allow ranges, I noted that the interface is currently limiting to 4 CIDR notation IPv4 ranges, and there is no way to add additional fields.

Can someone just patch in the ability to add additional IP allow rules, similar to the add location button when configuring a Proxy Host? That is the primary issue of this ticket.

If someone does that, could you add a button to "Configure Cloudflare Allow Rules" that will do a dynamic query to https://www.cloudflare.com/ips-v4 and add an allow rule for each noted range? This is the secondary request I am combining.

How can you configure SSL Certificate Pinning, and serve pages only to clients authenticated presenting an allowed SSL Certificate; so that the Origin CA Certificate can be configured from Cloudflare? This is a question that I have, because it's the last piece of this puzzle. This would prevent unauthenticated hosts from spoofing Cloudflare IP ranges to access Nginx.

@rapidbnnuy commented on GitHub (Oct 11, 2020): I'm really combining two separate issues here, but allow me to explain further. My goal as an End User is to configured nginx-proxy-manager with full protection behind Cloudflare. That may be an edge case, and some or all of the requested features may not warrant implementation for what nginx-proxy-manager is looking to provide. However, from past posts I have identified support for trying to make this happen, so I felt like opening this issue would be worthwhile as an enhancement request. Cloudflare offers maximum protection when the destination web server is configured for HSTS with Preload, TLS 1.3, HTTP/2 (or 3), Configured for IP Allow for Cloudflare IPv4 ranges, and Deny All for all other traffic, and SSL Certificate Pinning with Cloudflare's generated Origin CA Certificate. There are further features, but that's enough to protect your IP address or web server from being exposed to the Internet without going through Cloudflare. HSTS with Preload is currently in the build and working, as is HTTP/2 and TLS 1.3 with Wildcard SSL Certificate with automatic DNS verification with Cloudflare. That's significant. However, I have been unable to locate any assistance for how to configure the Origin CA Certificate or the IP Allow Ranges. Upon attempting to configure the IP Allow ranges, I noted that the interface is currently limiting to 4 CIDR notation IPv4 ranges, and there is no way to add additional fields. **Can someone just patch in the ability to add additional IP allow rules, similar to the add location button when configuring a Proxy Host?** That is the primary issue of this ticket. **If someone does that, could you add a button to "Configure Cloudflare Allow Rules" that will do a dynamic query to https://www.cloudflare.com/ips-v4 and add an allow rule for each noted range?** This is the secondary request I am combining. **How can you configure SSL Certificate Pinning, and serve pages only to clients authenticated presenting an allowed SSL Certificate; so that the Origin CA Certificate can be configured from Cloudflare?** This is a question that I have, because it's the last piece of this puzzle. This would prevent unauthenticated hosts from spoofing Cloudflare IP ranges to access Nginx.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@Kipjr commented on GitHub (Oct 17, 2020):

github.com/jc21/nginx-proxy-manager@e3399e1035/frontend/js/app/nginx/access/form.js (L116)

I think this is the culprit.

@Kipjr commented on GitHub (Oct 17, 2020): https://github.com/jc21/nginx-proxy-manager/blob/e3399e10358d61b524d4b3f7edec39e604756d03/frontend/js/app/nginx/access/form.js#L116 I think this is the culprit.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@carterminearIMT commented on GitHub (Oct 19, 2020):

I came here looking to the exact same things you are trying to do. I am hoping this gets implemented as well!

@carterminearIMT commented on GitHub (Oct 19, 2020): I came here looking to the exact same things you are trying to do. I am hoping this gets implemented as well!

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@rapidbnnuy commented on GitHub (Oct 23, 2020):

OK, so I think we have a clear picture of functionality that is not currently present, and the community is showing some interest in this feature being expanded. What are the next steps for this? Does it need further support, or can it be assigned?

@rapidbnnuy commented on GitHub (Oct 23, 2020): OK, so I think we have a clear picture of functionality that is not currently present, and the community is showing some interest in this feature being expanded. What are the next steps for this? Does it need further support, or can it be assigned?

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@rapidbnnuy commented on GitHub (Oct 23, 2020):

@carterminearIMT I was able to answer one of the questions I had a previous post. I'm not sure if it is helpful, but I did find out how to do SSL Certificate Pinning with nginx-proxy-manager, and this could help you secure your instance to only process requests from Cloudflare until this IP Allow List can be expanded. Even if it doesn't apply directly to you, I'm sure the information will be helpful to someone.

In CloudFlare, navigate to:
SSL/TLS --> Origin Server --> Create Certificate
Select: Let Cloudflare generate a private key and a CSR
Hostnames: *.domain.com, domain.com
Certificate Validity: 15 Years
Finally, click on Download and save your file as cloudflare.pem

Now here is where our setups are going to differ, but you need configure docker volumes to present this file to the container as:
/data/custom_ssl/cloudflare.pem

For me that is done by adding:

volumes:
  ./data/custom_ssl/cloudflare.pem:/data/custom_ssl/cloudflare.pem

This allows me to keep my file in a subdirectory next to my dockerfile, but you may adjust to your needs.

Finally, we need to configure nginx-proxy-manager to use SSL Certificate Pinning with this certificate. This is done by navigating to your Proxy Host, and the Advanced Tab and adding the following code for nginx:

  #Turn on Authenticated Origin Pulls for Cloudflare
  ssl_client_certificate /data/custom_ssl/cloudflare.pem;
  ssl_verify_client on;

Still just one more step, in Cloudflare, navigate to SSL/TLS --> Origin Server --> Authenticated Origin Pulls, toggle this to ON.

Now when you load your site through Cloudflare it should load fine, but if you try editing your HOSTS file to point your domain to your external IP, it should give you an error about not presenting a certificate. This goes a step further than blocking external hosts by IP Allow, because this will block any host that cannot present an SSL certificate signed by a CloudFlare CA. I think it's a reasonable workaround until this can be fixed. Honestly as you can see in my prior post, I recommend doing both.

@rapidbnnuy commented on GitHub (Oct 23, 2020): @carterminearIMT I was able to answer one of the questions I had a previous post. I'm not sure if it is helpful, but I did find out how to do SSL Certificate Pinning with nginx-proxy-manager, and this could help you secure your instance to only process requests from Cloudflare until this IP Allow List can be expanded. Even if it doesn't apply directly to you, I'm sure the information will be helpful to someone. In CloudFlare, navigate to: SSL/TLS --> Origin Server --> Create Certificate Select: Let Cloudflare generate a private key and a CSR Hostnames: *.domain.com, domain.com Certificate Validity: 15 Years Finally, click on Download and save your file as cloudflare.pem Now here is where our setups are going to differ, but you need configure docker volumes to present this file to the container as: `/data/custom_ssl/cloudflare.pem` For me that is done by adding: ``` volumes: ./data/custom_ssl/cloudflare.pem:/data/custom_ssl/cloudflare.pem ``` This allows me to keep my file in a subdirectory next to my dockerfile, but you may adjust to your needs. Finally, we need to configure nginx-proxy-manager to use SSL Certificate Pinning with this certificate. This is done by navigating to your Proxy Host, and the Advanced Tab and adding the following code for nginx: ``` #Turn on Authenticated Origin Pulls for Cloudflare ssl_client_certificate /data/custom_ssl/cloudflare.pem; ssl_verify_client on; ``` Still just one more step, in Cloudflare, navigate to SSL/TLS --> Origin Server --> Authenticated Origin Pulls, toggle this to ON. Now when you load your site through Cloudflare it should load fine, but if you try editing your HOSTS file to point your domain to your external IP, it should give you an error about not presenting a certificate. This goes a step further than blocking external hosts by IP Allow, because this will block any host that cannot present an SSL certificate signed by a CloudFlare CA. I think it's a reasonable workaround until this can be fixed. Honestly as you can see in my prior post, I recommend doing both.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@camlafit commented on GitHub (Oct 29, 2020):

Hello

Here at office we are same problem. We need to allow different remote users to our internal service.
4 ip range is not enough in this case.
Could be very nice to improve this behavior and allow without any restricted list.

@camlafit commented on GitHub (Oct 29, 2020): Hello Here at office we are same problem. We need to allow different remote users to our internal service. 4 ip range is not enough in this case. Could be very nice to improve this behavior and allow without any restricted list.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@rapidbnnuy commented on GitHub (Oct 29, 2020):

All I can say is keep upvoting this enhancement to bring attention to it. It's not currently on the roadmap.

@rapidbnnuy commented on GitHub (Oct 29, 2020): All I can say is keep upvoting this enhancement to bring attention to it. It's not currently on the roadmap.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@Xenthys commented on GitHub (Dec 8, 2020):

You can see NPM pulling Cloudflare's ranges when it starts, same for AWS, but I ignore what they are used for at the moment. Maybe those can be used in some way but no idea how, my current workaround is to use the NGINX custom configuration tab on every host I want to restrict to Cloudflare.

# Cloudflare IP addresses
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/12;
allow 172.64.0.0/13;
allow 131.0.72.0/22;
deny all;

Good enough to me until such a feature would appear on the roadmap!

@Xenthys commented on GitHub (Dec 8, 2020): You can see NPM pulling Cloudflare's ranges when it starts, same for AWS, but I ignore what they are used for at the moment. Maybe those can be used in some way but no idea how, my current workaround is to use the NGINX custom configuration tab on every host I want to restrict to Cloudflare. ```nginx # Cloudflare IP addresses allow 173.245.48.0/20; allow 103.21.244.0/22; allow 103.22.200.0/22; allow 103.31.4.0/22; allow 141.101.64.0/18; allow 108.162.192.0/18; allow 190.93.240.0/20; allow 188.114.96.0/20; allow 197.234.240.0/22; allow 198.41.128.0/17; allow 162.158.0.0/15; allow 104.16.0.0/12; allow 172.64.0.0/13; allow 131.0.72.0/22; deny all; ``` Good enough to me until such a feature would appear on the roadmap!

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@ArtisanByteCrafter commented on GitHub (Feb 11, 2021):

Chiming in to voice my support for either comma-seperated allow lists, or ability to create additional ones. Ideally, a dropdown of providers like "Allow Cloudflare IPs" that dynamically provisions the allow list from https://www.cloudflare.com/ips-v4 would be an elegant solution as well.

@ArtisanByteCrafter commented on GitHub (Feb 11, 2021): Chiming in to voice my support for either comma-seperated allow lists, or ability to create additional ones. Ideally, a dropdown of providers like "Allow Cloudflare IPs" that dynamically provisions the allow list from https://www.cloudflare.com/ips-v4 would be an elegant solution as well.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@Matt-CyberGuy commented on GitHub (Mar 31, 2021):

I desperately need this feature implemented as well. Also, I've noticed it's very spotty. I have to disable and re-enable a half dozen times before it seems to take effect.

@Matt-CyberGuy commented on GitHub (Mar 31, 2021): I desperately need this feature implemented as well. Also, I've noticed it's very spotty. I have to disable and re-enable a half dozen times before it seems to take effect.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@rapidbnnuy commented on GitHub (Mar 31, 2021):

@matt-cylanda I'm not sure if you noticed, right above your post there was a mention. If you click on it, this will take you to a pending merge that fixes this issue. It looks like it is just awaiting approval, and should be released into the code base shortly. The fix will add a button that allows additional ranges to be added. Hooray!

@rapidbnnuy commented on GitHub (Mar 31, 2021): @matt-cylanda I'm not sure if you noticed, right above your post there was a mention. If you click on it, this will take you to a pending merge that fixes this issue. It looks like it is just awaiting approval, and should be released into the code base shortly. The fix will add a button that allows additional ranges to be added. Hooray!

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@Matt-CyberGuy commented on GitHub (Mar 31, 2021):

Thanks, I started to follow it and realized I was using a jlesage/nginx-proxy-manager instead of this one. I installed the one listed, but keep getting 'bad gateway' when trying to login with the default credentials.

@Matt-CyberGuy commented on GitHub (Mar 31, 2021): Thanks, I started to follow it and realized I was using a jlesage/nginx-proxy-manager instead of this one. I installed the one listed, but keep getting 'bad gateway' when trying to login with the default credentials.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@chaptergy commented on GitHub (May 12, 2021):

As the PR is now merged, I will close this issue.

@chaptergy commented on GitHub (May 12, 2021): As the PR is now merged, I will close this issue.

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@itsKV commented on GitHub (Apr 23, 2022):

You can see NPM pulling Cloudflare's ranges when it starts, same for AWS, but I ignore what they are used for at the moment. Maybe those can be used in some way but no idea how, my current workaround is to use the NGINX custom configuration tab on every host I want to restrict to Cloudflare.
# Cloudflare IP addresses
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/12;
allow 172.64.0.0/13;
allow 131.0.72.0/22;
deny all;
Good enough to me until such a feature would appear on the roadmap!

Yeah. I have seen the logs where the npm is pulling cloudflare's ips from api. But how to map those pulled list of ips to a proxy host? Because, the default access list is 'Publically Accessible' and there is no any reference point where we point the pulled list to particular host.
Any light on this?

@itsKV commented on GitHub (Apr 23, 2022): > You can see NPM pulling Cloudflare's ranges when it starts, same for AWS, but I ignore what they are used for at the moment. Maybe those can be used in some way but no idea how, my current workaround is to use the NGINX custom configuration tab on every host I want to restrict to Cloudflare. > > ```nginx > # Cloudflare IP addresses > allow 173.245.48.0/20; > allow 103.21.244.0/22; > allow 103.22.200.0/22; > allow 103.31.4.0/22; > allow 141.101.64.0/18; > allow 108.162.192.0/18; > allow 190.93.240.0/20; > allow 188.114.96.0/20; > allow 197.234.240.0/22; > allow 198.41.128.0/17; > allow 162.158.0.0/15; > allow 104.16.0.0/12; > allow 172.64.0.0/13; > allow 131.0.72.0/22; > deny all; > ``` > > Good enough to me until such a feature would appear on the roadmap! Yeah. I have seen the logs where the npm is pulling cloudflare's ips from api. But how to map those pulled list of ips to a proxy host? Because, the default access list is 'Publically Accessible' and there is no any reference point where we point the pulled list to particular host. Any light on this?

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@tinyaustralia commented on GitHub (Aug 9, 2024):

The location on the NPM container for these IP ranges is here:

/etc/nginx/conf.d/include/ip_ranges.conf

You could then mount this to the host (Not Tested)

@tinyaustralia commented on GitHub (Aug 9, 2024): The location on the NPM container for these IP ranges is here: `/etc/nginx/conf.d/include/ip_ranges.conf` You could then mount this to the host (Not Tested)

kerem commented

2026-02-26 06:33:14 +03:00

Author

Owner

@josh817 commented on GitHub (Nov 23, 2024):

@RapidRabbit-11485 I am noticing on my docker container that when I create a custom cert from the .pem (origin) and .key (private) Cloudflare provides, it puts the private key in /data/custom_ssl/npm-#/privkey.pem where # is sequentially autoassigned as you add certs. Is this the .pem that is meant to be referenced? If so, when I do this NPM changes that status of my proxy host to Offline. Likewise if I use the Origin .pem.

#Turn on Authenticated Origin Pulls for Cloudflare
ssl_client_certificate /data/custom_ssl/cloudflare.pem;
ssl_verify_client on;

Furthermore, if you go the route of allowing Cloudflare Trusted IPv4 and deny all other, while also using:

real_ip_header X-Forwarded-For;
set_real_ip_from [Cloudflare IPv4 address]
set_real_ip_from [Cloudflare IPv4 addresses...]

in nginx.conf for things like fail2ban IP table dropping, it results in 403 Forbidden. I assume this is because NPM is grabbing the real IP of the Client and no longer looking at the Cloudflare IP's we just allowed? We still need the Client IP so we can tell Cloudflare to apply a block rule.

@josh817 commented on GitHub (Nov 23, 2024): @RapidRabbit-11485 I am noticing on my docker container that when I create a custom cert from the .pem (origin) and .key (private) Cloudflare provides, it puts the private key in /data/custom_ssl/npm-#/privkey.pem where # is sequentially autoassigned as you add certs. Is this the .pem that is meant to be referenced? If so, when I do this NPM changes that status of my proxy host to Offline. Likewise if I use the Origin .pem. ``` #Turn on Authenticated Origin Pulls for Cloudflare ssl_client_certificate /data/custom_ssl/cloudflare.pem; ssl_verify_client on; ``` Furthermore, if you go the route of allowing Cloudflare Trusted IPv4 and deny all other, while also using: ``` real_ip_header X-Forwarded-For; set_real_ip_from [Cloudflare IPv4 address] set_real_ip_from [Cloudflare IPv4 addresses...] ``` in nginx.conf for things like fail2ban IP table dropping, it results in 403 Forbidden. I assume this is because NPM is grabbing the real IP of the Client and no longer looking at the Cloudflare IP's we just allowed? We still need the Client IP so we can tell Cloudflare to apply a block rule.

Rows
Columns

[GH-ISSUE #615] IP Allow List / CloudFlare Trusted IPs #517