[GH-ISSUE #4821] ACL with a ressource as a source #9893

Open
opened 2026-08-05 01:23:52 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @eveyraud on GitHub (Nov 19, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4821

Hi,
I currently have a homelab infrastructure that utilizes a VPS as an entry point. This VPS is configured to perform DNAT to my internal servers, which are connected as peers within a NetBird network.

After not touching my setup for a while, I've recently encountered "connection refused" errors when attempting to access my services. Upon investigation, I've realized that my understanding or the past behavior of NetBird's "ALL" group might have changed.

Previously, it seemed that the "ALL" group within NetBird's access control policies allowed access from foreign IPs (public IPs of my external clients) as a source. However, it now appears that the "ALL" group correctly encompasses only known NetBird peers. This shift seems to be the root cause of the "connection refused" messages, as external clients are no longer able to establish connections.

NetBird's "Networks" feature is designed to allow NetBird peers to access devices not running the NetBird agent through a designated routing peer. My VPS likely functions as such a routing peer, forwarding traffic into my NetBird network. The challenge now is ensuring that the initial external client connection, DNATed by the VPS, is properly authorized by NetBird's access control.

Do you know if there's a solution or a recommended approach in NetBird to allow external public IPs (clients that are not NetBird peers) to access services behind a routing peer via DNAT on the VPS? Is NetBird still suitable for this specific type of infrastructure setup where external clients need to access internal services through a DNAT-configured entry point?

Translated

Originally created by @eveyraud on GitHub (Nov 19, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4821 Hi, I currently have a homelab infrastructure that utilizes a VPS as an entry point. This VPS is configured to perform DNAT to my internal servers, which are connected as peers within a NetBird network. After not touching my setup for a while, I've recently encountered "connection refused" errors when attempting to access my services. Upon investigation, I've realized that my understanding or the past behavior of NetBird's "ALL" group might have changed. Previously, it seemed that the "ALL" group within NetBird's access control policies allowed access from foreign IPs (public IPs of my external clients) as a source. However, it now appears that the "ALL" group correctly encompasses only known NetBird peers. This shift seems to be the root cause of the "connection refused" messages, as external clients are no longer able to establish connections. NetBird's "Networks" feature is designed to allow NetBird peers to access devices not running the NetBird agent through a designated routing peer. My VPS likely functions as such a routing peer, forwarding traffic into my NetBird network. The challenge now is ensuring that the initial external client connection, DNATed by the VPS, is properly authorized by NetBird's access control. Do you know if there's a solution or a recommended approach in NetBird to allow external public IPs (clients that are not NetBird peers) to access services behind a routing peer via DNAT on the VPS? Is NetBird still suitable for this specific type of infrastructure setup where external clients need to access internal services through a DNAT-configured entry point? _Translated_
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#9893