docs(access-control): correct policy direction claim across docs (#739)

Earlier docs asserted that policies using `ALL`, `ICMP`, or portless
`TCP`/`UDP` must be bidirectional. Data-plane testing on NetBird
0.59.10 shows the engine honors the direction flag for every
protocol — peer-d's iptables only installs the destination-side
`ACCEPT` rule, so reverse-initiated traffic is dropped at the source
even when the policy uses `ALL` or `ICMP`. The greyed-out direction
toggle in the dashboard is a UX guardrail, not an enforcement gap.

- manage-network-access.mdx: rewrite the Policies overview and
  Multiple Mesh Networks paragraphs; drop the outdated `Note`
  callout; trim Creating Policies guidance.
- access-control/index.mdx: rewrite Protocol-Specific Behavior;
  drop the "Always Bidirectional (regardless of UI setting)" list.
- implement-zero-trust.mdx: soften TCP/UDP+ports framing.
- troubleshooting-client.mdx: drop "always true for the protocol
  `ALL`" clause from the bidirectional-rule bullet.

Network-resource (routing peer) policies remain genuinely
unidirectional — that statement preserved.

src/pages/help/troubleshooting-client.mdx

@@ -788,7 +788,7 @@ Just like with the previous section you can loosen the above example by:
 
 - replacing `access:srv-c` _Group_ with `access:int-net1` _Group_,
 - allowing `ALL` protocol, _Ports_ will become greyed out because all traffic will be allowed,
-- creating a bidirectional rule (both arrows should be green), always true for the protocol `ALL`,
+- creating a bidirectional rule (both arrows should be green),
 - selecting a different source group from the pool assigned to `peer-a`,
   - it could be built-in `All` group, but it is discouraged,
 - selecting a different destination group from the pool assigned to `peer-b`,

src/pages/manage/access-control/index.mdx

@@ -288,18 +288,7 @@ Policies to network resources control access to the network behind the routing p
 
 ### Protocol-Specific Behavior
 
-Policy directionality also depends on the protocol selected:
-
-**Always Bidirectional (regardless of UI setting):**
-
-- **ALL protocol**: Both directions can always initiate connections
-- **ICMP**: Both directions can always initiate (for ping, etc.)
-- **TCP/UDP without specific ports**: Both directions can initiate connections
-
-**Can Be Unidirectional (when ports are specified):**
-
-- **TCP with specific ports**: Can be unidirectional (only source initiates on those ports)
-- **UDP with specific ports**: Can be unidirectional (only source initiates on those ports)
+The data-plane honors the policy's direction flag for every protocol — `ALL`, `ICMP`, and `TCP`/`UDP` with or without specific ports.
 
 Example:
 

src/pages/manage/access-control/manage-network-access.mdx

@@ -45,7 +45,7 @@ Policies act as rules governing how different resources (peers) can communicate
 
 Policies are processed when the Management service shares a network map with all peers of your account. Because you can only create ALLOW policies, there is no processing order or priority. So, the decision to distribute peer information is based on its association with a group belonging to an existing policy.
 
-For ICMP and ALL protocols, as well as for TCP and UDP protocols **without** specific port restrictions, communication between groups listed in the source and destination fields is bidirectional. This means that both source and destination groups can initiate connections with each other. To establish one-way connections, you must specify a protocol (UDP or TCP), along with a port.
+Each policy has a direction flag — bidirectional (both groups can initiate) or unidirectional (only the source initiates) — and the data-plane honors it for every protocol, including `ALL`, `ICMP`, and `TCP`/`UDP` without specific ports.
 
 <Note>
 If you need to allow peers from the same group to communicate with each other, you can do so by adding the same group to the `Source` and `Destination` lists.
@@ -62,9 +62,9 @@ The `Default` policy is created when you first create your account. This policy
 </Note>
 
 ### Multiple Mesh Networks
-As mentioned above, policies are bidirectional by default, essentially controlling how your network behaves as a mesh network. However, for TCP and UDP protocols, if you specify ports in the policy, it can become unidirectional.
+Policies shape how your network behaves as a mesh. Bidirectional policies suit clusters or service pairs that need to talk both ways; unidirectional policies are the typical Zero Trust pattern.
 
-There is a `Default` policy, which configures a default mesh connection between all peers of your network. With policies, you can define smaller mesh networks by grouping peers and adding these groups to `Source` and `Destination` lists. Additionally, you can create unidirectional policies to restrict traffic between groups for TCP and UDP protocols if you define ports.
+There is a `Default` policy, which configures a default mesh connection between all peers of your network. With policies, you can define smaller mesh networks by grouping peers and adding these groups to `Source` and `Destination` lists.
 
 ## Managing Policies
 
@@ -78,7 +78,7 @@ In the popup, specify connection `Source` and `Destination` groups. You can sele
 
 You can limit access to specific protocol and ports by selecting the `Protocol` and providing the port numbers in the `Ports` field.
 Starting version `0.48` NetBird supports port ranges in policies, allowing you to specify a range of ports in the format `start-end` (e.g., `8000-9000`).
-Make sure to set traffic direction only when TCP or UDP protocols are selected. Finally, provide a name and description for your policy.
+Set the `Direction` field, then provide a name and description for your policy.
 
 <p>
     <img src="/docs-static/img/manage/access-control/create-rule.png" alt="high-level-dia" className="imagewrapper"/>
@@ -94,10 +94,6 @@ Once you have finished configuring the policy, click `Add Policy` to save it. Yo
     Because of its permissiveness, new policies will take effect once you remove the `Default` policy.
 </Note>
 
-<Note>
-Protocol type All or ICMP must be bi-directional. Also unidirectional traffic for TCP and UDP protocol requires at least one port to be defined.
-</Note>
-
 ### Adding peers to groups
 If you create a new group when defining a policy, you will need to add a peer to the group for the policy to take effect.
 You can assign a peer to a group by accessing the `Peers` section. Then, choose the specific peer you want to assign to a group. Click on the `Assigned Groups` select box and select the group(s) you wish to assign to this peer.

src/pages/use-cases/security/implement-zero-trust.mdx

@@ -369,7 +369,7 @@ Most application traffic has a clear client and server:
 
 In NetBird:
 
-- Use TCP (Transmission Control Protocol, connection-oriented) or UDP (User Datagram Protocol, connectionless) with exact ports to create unidirectional rules where only the source initiates the connection.
+- For Zero Trust enforcement, prefer `TCP` (connection-oriented) or `UDP` (connectionless) with exact ports and the direction set to unidirectional, so only the source initiates the connection.
 - "All" protocol policies are broad. Limit them to very specific scopes or emergency use.
 - Portless rules are effectively "all ports" and should be treated as wide open. These are not recommended for Zero Trust.