One-way direction to a peer #1738

Open
opened 2025-11-20 06:05:46 -05:00 by saavagebueno · 8 comments
Owner

Originally created by @tropnikovvl on GitHub (Mar 19, 2025).

Is your feature request related to a problem? Please describe.
Currently, policies only allow you to configure two-way access to peers, meaning peer A can access peer B, and vice versa.

Describe the solution you'd like
It would be nice to be able to set one-way access to peers, i.e. peer A can access peer B, but peer B cannot initiate a connection to peer A. The implication is that peer B will be able to respond to peer A, but within the scope of a session initiated by peer A.

Additional context
If a server with one of the peers is taken over by an attacker, then the attacker will automatically gain access to the entire network accessible to the peer.
This would close this attack surface.

Originally created by @tropnikovvl on GitHub (Mar 19, 2025). **Is your feature request related to a problem? Please describe.** Currently, policies only allow you to configure two-way access to peers, meaning peer A can access peer B, and vice versa. **Describe the solution you'd like** It would be nice to be able to set one-way access to peers, i.e. peer A can access peer B, but peer B cannot initiate a connection to peer A. The implication is that peer B will be able to respond to peer A, but within the scope of a session initiated by peer A. **Additional context** If a server with one of the peers is taken over by an attacker, then the attacker will automatically gain access to the entire network accessible to the peer. This would close this attack surface.
saavagebueno added the feature-request label 2025-11-20 06:05:46 -05:00
Author
Owner

@nazarewk commented on GitHub (Mar 19, 2025):

It is already possible to unidirectional rule, but you need to limit it to either TCP or UDP and select all ports to be accessed.

Other than that it seems like a reasonable feature.

@nazarewk commented on GitHub (Mar 19, 2025): It is already possible to unidirectional rule, but you need to limit it to either TCP or UDP and select all ports to be accessed. Other than that it seems like a reasonable feature.
Author
Owner

@tropnikovvl commented on GitHub (Mar 19, 2025):

@nazarewk
Indeed, I didn't know about this.
But I can't select the range.
Image

@tropnikovvl commented on GitHub (Mar 19, 2025): @nazarewk Indeed, I didn't know about this. But I can't select the range. ![Image](https://github.com/user-attachments/assets/86cd7882-14aa-4425-be1b-5566c9e6ffd5)
Author
Owner

@fti7 commented on GitHub (Mar 19, 2025):

+1 it should be possible to select "all protocols". Even if it creates seperate ones for UDP/TCP/ICMP etc. in the Background (Shouldnt be visible to the user)

@fti7 commented on GitHub (Mar 19, 2025): +1 it should be possible to select "all protocols". Even if it creates seperate ones for UDP/TCP/ICMP etc. in the Background (Shouldnt be visible to the user)
Author
Owner

@nazarewk commented on GitHub (Mar 19, 2025):

there is already a feature request for port ranges https://github.com/netbirdio/netbird/issues/2320

@nazarewk commented on GitHub (Mar 19, 2025): there is already a feature request for port ranges https://github.com/netbirdio/netbird/issues/2320
Author
Owner

@tropnikovvl commented on GitHub (Mar 22, 2025):

@nazarewk
I made changes in UI and backend, and it is displayed without problems.

Image

Do you know what pitfalls there might be if you remove this restriction?
Why is it needed by the way?
https://github.com/netbirdio/netbird/blob/main/management/server/http/handlers/policies/policies_handler.go#L270

@tropnikovvl commented on GitHub (Mar 22, 2025): @nazarewk I made changes in UI and backend, and it is displayed without problems. ![Image](https://github.com/user-attachments/assets/1aeae3f3-42a1-4b5e-94cc-6659152250d7) Do you know what pitfalls there might be if you remove this restriction? Why is it needed by the way? https://github.com/netbirdio/netbird/blob/main/management/server/http/handlers/policies/policies_handler.go#L270
Author
Owner

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

Aggregating all issues related to unidirectional rule port ranges I was able to identify:

@nazarewk commented on GitHub (Apr 18, 2025): Aggregating all issues related to unidirectional rule port ranges I was able to identify: - https://github.com/netbirdio/netbird/issues/3547 - https://github.com/netbirdio/netbird/issues/2320 - https://github.com/netbirdio/netbird/issues/1995
Author
Owner

@easyjoh commented on GitHub (Apr 25, 2025):

Port ranges are already in the API (https://docs.netbird.io/api/resources/policies#create-a-policy) so it should "simply" be reflected in the UI.
@tropnikovvl, may I suggest you create a pull request to share your work?

@easyjoh commented on GitHub (Apr 25, 2025): Port ranges are already in the API (https://docs.netbird.io/api/resources/policies#create-a-policy) so it should "simply" be reflected in the UI. @tropnikovvl, may I suggest you create a pull request to share your work?
Author
Owner

@tropnikovvl commented on GitHub (Apr 26, 2025):

Hi @easyjoh ,

This is indeed in the API, but these rules cannot be applied because there is this limitation

		case types.PolicyRuleProtocolALL, types.PolicyRuleProtocolICMP:
			if len(pr.Ports) != 0 || len(pr.PortRanges) != 0 {
				util.WriteError(r.Context(), status.Errorf(status.InvalidArgument, "for ALL or ICMP protocol ports is not allowed"), w)
				return
			}
			if !pr.Bidirectional {
				util.WriteError(r.Context(), status.Errorf(status.InvalidArgument, "for ALL or ICMP protocol type flow can be only bi-directional"), w)
				return
			}
		case types.PolicyRuleProtocolTCP, types.PolicyRuleProtocolUDP:
			if !pr.Bidirectional && (len(pr.Ports) == 0 || len(pr.PortRanges) != 0) {
				util.WriteError(r.Context(), status.Errorf(status.InvalidArgument, "for ALL or ICMP protocol type flow can be only bi-directional"), w)
				return
			}
		}

https://github.com/netbirdio/netbird/blob/main/management/server/http/handlers/policies/policies_handler.go#L259

@tropnikovvl commented on GitHub (Apr 26, 2025): Hi @easyjoh , This is indeed in the API, but these rules cannot be applied because there is this limitation ``` case types.PolicyRuleProtocolALL, types.PolicyRuleProtocolICMP: if len(pr.Ports) != 0 || len(pr.PortRanges) != 0 { util.WriteError(r.Context(), status.Errorf(status.InvalidArgument, "for ALL or ICMP protocol ports is not allowed"), w) return } if !pr.Bidirectional { util.WriteError(r.Context(), status.Errorf(status.InvalidArgument, "for ALL or ICMP protocol type flow can be only bi-directional"), w) return } case types.PolicyRuleProtocolTCP, types.PolicyRuleProtocolUDP: if !pr.Bidirectional && (len(pr.Ports) == 0 || len(pr.PortRanges) != 0) { util.WriteError(r.Context(), status.Errorf(status.InvalidArgument, "for ALL or ICMP protocol type flow can be only bi-directional"), w) return } } ``` https://github.com/netbirdio/netbird/blob/main/management/server/http/handlers/policies/policies_handler.go#L259
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#1738