SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-07-02 12:12:43 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Resource unable to access resources on Netbird network #1977

New Issue
Closed
opened 2025-11-20 06:10:32 -05:00 by saavagebueno · 7 comments
saavagebueno commented 2025-11-20 06:10:32 -05:00
Owner
Copy Link

Originally created by @sahps on GitHub (Jun 18, 2025).

This may or may not be a bug, but I'm struggling to get something working.

Details of the systems
HPVNB01
Netbird management, signal, relay, coturn server
Hosted in Azure
No access to any other network, entirely seperate
Has netbird client installed

HPVNB02
Netbird client
Serves as the entry point to the rest of the network.
The plan is to not install netbird on every server, and instead route out of this node

HPVDOCK01
Docker container host

Groups

System Group Type
HPVDOCK01 Zabbix Server Resource
HPVNB01 Linux Servers Peer

Network
Image

The internal on-premise network has routes configured on the firewall to correctly pass traffic destined for netbird clients to HPVNB02.

Netbird Resource
Image

Policy
There is a policy to allow Zabbix Server access to Linux Servers on tcp/10050
Image

Problem
I need HPVDOCK01 to access HPVNB01 on its LAN IP.
So that is: HPVDOCK01 > Router > HPVNB02 > Netbird > HPVNB01
However the above policy isn't correct as traffic stops on HPVNB02 and doesn't get passed onto the wt0 interface.
If I create a temporary new policy for All <> All, the connectivity works.

So the question is, how do I create a policy to allow an off-network resource to access the LAN IP of an on-network peer?

Originally created by @sahps on GitHub (Jun 18, 2025). This may or may not be a bug, but I'm struggling to get something working. **Details of the systems** HPVNB01 Netbird management, signal, relay, coturn server Hosted in Azure No access to any other network, entirely seperate Has netbird client installed HPVNB02 Netbird client Serves as the entry point to the rest of the network. The plan is to not install netbird on every server, and instead route out of this node HPVDOCK01 Docker container host **Groups** | System | Group | Type | |-----------|---------------|----------| | HPVDOCK01 | Zabbix Server | Resource | | HPVNB01 | Linux Servers | Peer | **Network** ![Image](https://github.com/user-attachments/assets/708b77f1-99e9-4505-bd0e-74b7e13820a9) The internal on-premise network has routes configured on the firewall to correctly pass traffic destined for netbird clients to HPVNB02. **Netbird Resource** ![Image](https://github.com/user-attachments/assets/d05e7f68-55e6-45c3-857f-1cded1e8d612) **Policy** There is a policy to allow `Zabbix Server` access to `Linux Servers` on `tcp/10050` ![Image](https://github.com/user-attachments/assets/5f4324ce-70ef-4bf4-85a2-0773c796abd5) **Problem** I need HPVDOCK01 to access HPVNB01 on its LAN IP. So that is: `HPVDOCK01 > Router > HPVNB02 > Netbird > HPVNB01` However the above policy isn't correct as traffic stops on HPVNB02 and doesn't get passed onto the wt0 interface. If I create a temporary new policy for `All <> All`, the connectivity works. So the question is, how do I create a policy to allow an off-network resource to access the LAN IP of an on-network peer?
saavagebueno added the networkingconfig-issue labels 2025-11-20 06:10:33 -05:00
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jun 18, 2025):

This is kind of Site-to-VPN scenario (similar to Site-to-Site tunnel), as far as I know, it would only work with Network Routes, not Network Resources.

@lixmal might be able to expand on why exactly that is, but i think it's something with (compared to Routes) Network firewall rules preventing forwarding, which Routes do not have and allow the traffic through just fine.

In coming weeks I will be doing:

  1. a PoC for site-to-site connectivity to verify it works
  2. expand & clarify the Network Routes documentation:
  • what is the current state?
  • what to watch out for when using those? (TLDR; be wary of lack of Access Groups)
  • what are current use cases for those: basically only Exit Node & Site-to-Site VPN
@nazarewk commented on GitHub (Jun 18, 2025): This is kind of Site-to-VPN scenario (similar to Site-to-Site tunnel), as far as I know, it would only work with Network Routes, not Network Resources. @lixmal might be able to expand on why exactly that is, but i think it's something with (compared to Routes) Network firewall rules preventing forwarding, which Routes do not have and allow the traffic through just fine. In coming weeks I will be doing: 1. a PoC for site-to-site connectivity to verify it works 2. expand & clarify the Network Routes documentation: - what is the current state? - what to watch out for when using those? (TLDR; be wary of lack of Access Groups) - what are current use cases for those: basically only Exit Node & Site-to-Site VPN
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@sahps commented on GitHub (Jun 18, 2025):

Thank you for your response.

but i think it's something with (compared to Routes) Network firewall rules preventing forwarding

This seems to be what I'm seeing. The system gets so close to working, I feel like this is close to being ready.

What I think is that the policies system doesn't support using resources as a source.

If I take a policy that has group1 > group2 : tcp/10050 then this won't allow traffic to flow from a resource to a remote connected netbird client. But if I change this rule to any > group2 : tcp/10050 then it works.

For my real examples above, the new policy then looks like

Image

So the routing part is fine, just the traffic is being blocked by the policy/firewall system.

@sahps commented on GitHub (Jun 18, 2025): Thank you for your response. > but i think it's something with (compared to Routes) Network firewall rules preventing forwarding This seems to be what I'm seeing. The system gets so close to working, I feel like this is close to being ready. What I think is that the policies system doesn't support using resources as a source. If I take a policy that has `group1 > group2 : tcp/10050` then this won't allow traffic to flow from a resource to a remote connected netbird client. But if I change this rule to `any > group2 : tcp/10050` then it works. For my real examples above, the new policy then looks like ![Image](https://github.com/user-attachments/assets/049fa62c-5530-4831-a671-e95f3f917c46) So the routing part is fine, just the traffic is being blocked by the policy/firewall system.
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jun 18, 2025):

yeah, Resources make the traffic go only one way: from NetBird into the routed network, but cannot route it back.
To set it up both ways, you'll need a Network Route.

@nazarewk commented on GitHub (Jun 18, 2025): yeah, Resources make the traffic go only one way: from NetBird into the routed network, but cannot route it back. To set it up both ways, you'll need a Network Route.
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@sahps commented on GitHub (Jun 18, 2025):

Okay, I'll try to figure out Network Routes as I couldn't get this to work the first time I tried.

Is there a plan to allow communication to Network Resources the way I attempted? It seems like it is just the software firewall that is preventing the traffic from flowing.

@sahps commented on GitHub (Jun 18, 2025): Okay, I'll try to figure out Network Routes as I couldn't get this to work the first time I tried. Is there a plan to allow communication to Network Resources the way I attempted? It seems like it is just the software firewall that is preventing the traffic from flowing.
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@lixmal commented on GitHub (Jun 18, 2025):

@sahps it should also be possible with Networks, try the following:

Access policy from the peer to be accessed to the resource with minimal access (e.g. icmp).
This sets up nat, routing and the peer connection.

Then another policy from the peer that is in front of the resource to the peer that is to be accessed, with the desired access permissions.

Masquerading needs to be enabled on the routing peer for this to work.

Also if you don't already have a default routing pointing to the routing peer on the resource machine: you will need to statically route the 100.x.x.x address or subnet. But since this is a container, it should be fine.

As you already found out, resources can only be specified in the destination portion of policies.

@lixmal commented on GitHub (Jun 18, 2025): @sahps it should also be possible with `Networks`, try the following: Access policy from the peer to be accessed to the resource with minimal access (e.g. icmp). This sets up nat, routing and the peer connection. Then another policy from the *peer* that is in front of the resource to the peer that is to be accessed, with the desired access permissions. Masquerading needs to be enabled on the routing peer for this to work. Also if you don't already have a default routing pointing to the routing peer on the resource machine: you will need to statically route the 100.x.x.x address or subnet. But since this is a container, it should be fine. As you already found out, resources can only be specified in the destination portion of policies.
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@sahps commented on GitHub (Jun 18, 2025):

Thanks @lixmal , that seems like a workaround, but I wanted to use the original IP addresses so masquerading breaks this.

I'm thinking things like AD Domain Controllers on two different networks with netbird routing nodes connecting those networks together. They need to be able to communicate with each other in both directions, and using their original IP addresses.

I'll give Network Routers another go for now, and hope that Network Resources may get some more developer love in the future.

@sahps commented on GitHub (Jun 18, 2025): Thanks @lixmal , that seems like a workaround, but I wanted to use the original IP addresses so masquerading breaks this. I'm thinking things like AD Domain Controllers on two different networks with netbird routing nodes connecting those networks together. They need to be able to communicate with each other in both directions, and using their original IP addresses. I'll give Network Routers another go for now, and hope that Network Resources may get some more developer love in the future.
saavagebueno commented 2025-11-20 06:10:34 -05:00
Author
Owner
Copy Link

@lixmal commented on GitHub (Jun 18, 2025):

@sahps yes, network routes are the only way to do this without masquerading. Currently you have to pick either masquerading or route ACLs for network routes

@lixmal commented on GitHub (Jun 18, 2025): @sahps yes, network routes are the only way to do this without masquerading. Currently you have to pick either masquerading or route ACLs for network routes
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label config-issue networking
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#1977
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?