Skip to content

[Enhancement] IP-based allow/deny access control for Stream Hosts #5125

@Frew777

Description

@Frew777

Is your feature request related to a problem? Please describe.

Currently, Stream Hosts do not support any IP-based access control via the Nginx Proxy Manager UI, while nginx itself fully supports allow / deny directives in the stream context.

This creates a gap where:

  • Stream Hosts expose TCP ports to the network
  • There is no way to restrict access per Stream Host inside NPM
  • Users must rely on external firewall rules or manual nginx configuration

This breaks the “single pane of glass” approach that NPM provides for Proxy Hosts and makes Stream Hosts harder to manage securely, especially for services like SFTP, databases, or other TCP-based protocols where IP filtering is a common and sufficient control.


Describe the solution you'd like

Add IP-based allow/deny access control for Stream Hosts.

This could be implemented as either:

  • A simple allow/deny IP list directly in the Stream Host configuration, or
  • Reuse of existing Access Lists, limited strictly to IP filtering only (no HTTP authentication, no headers).

The generated nginx configuration would directly map to native stream directives, for example:

allow x.x.x.x;
deny all;

No application-layer authentication is expected or required.


Describe alternatives you've considered

  • Host-level firewall rules (iptables / nftables)
  • Custom nginx stream configuration managed outside of NPM
  • Restricting access at the upstream service level

While these approaches work, they require managing access control outside of NPM, reducing visibility, consistency, and ease of management compared to Proxy Hosts.


Additional context

  • nginx already supports IP filtering in the stream module
  • This request is not about adding HTTP authentication to Stream Hosts
  • Scope is intentionally limited to L4 IP allow/deny rules
  • Firewall-based filtering would still remain a best practice; this feature would improve usability and configuration parity within NPM

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions