add example for office posture check (#262)

src/components/NavigationDocs.jsx

@@ -87,11 +87,18 @@ export const docsNavigation = [
              isOpen: false,
              links: [
                  { title: 'Groups & Policies', href: '/how-to/manage-network-access' },
-                 { title: 'Posture Checks', href: '/how-to/manage-posture-checks' },
+                 { 
+                    title: 'Posture Checks', 
+                    href: '/how-to/manage-posture-checks',
+                    isOpen: false,
+                    links: [
+                        { title: 'Disable route when in the office', href: '/how-to/disabling-network-route-when-connecting-from-the-office' },
+                    ]
+                },
                  {
                      title: 'Integrate EDR',
                      href: '/how-to/endpoint-detection-and-response',
-                     isOpen: false,
+                     isOpen: false, 
                      links: [
                          { title: 'CrowdStrike Falcon', href: '/how-to/crowdstrike-edr' },
                      ]

src/pages/how-to/disabling-network-route-when-connecting-from-the-office.mdx

@@ -0,0 +1,102 @@
+
+
+# Connecting from the office
+A typical scenario administrators have is accessing their office networks remotely. With [Network routes](https://docs.netbird.io/how-to/routing-traffic-to-private-networks), NetBird makes this easy. Still, administrators often want to avoid routing their users’ traffic via NetBird when they are in the office. To solve this, administrators can leverage the power of [Posture Checks](https://docs.netbird.io/how-to/manage-posture-checks)and create policies that allow connection to the routing peers only if they are outside the office by using a [Peer Network Range](/how-to/manage-posture-checks#peer-network-range-check) posture check with a block action.
+
+## Example
+In the following scenario, our office network is on the subnet `192.168.1.0/24`. Let's assume all users will be part of the group `route-users`, and the routing peer for our office will be inside the group `route-nodes`.
+With this in mind, the goal is to create a Posture Check, create a Policy and assign a Posture Check to it, and finally create a Network Route that will expose the office subnet.
+
+### Create a Posture Check
+To create a Posture Check, navigate to the `Access Control -> Posture Checks` section in the NetBird dashboard and click on **Add Posture Check**.
+
+Select `Peer Network Range`.
+
+<p>
+    <img src="/docs-static/img/how-to-guides/posture-check-new-block-network-range.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+Select the `Block` action and click on `Add Network Range` to input your office subbnet `192.168.1.0/24`.
+<Note>
+Note that if you have multiple locations that you want to see excluded, you can add multiple network ranges.
+</Note>
+<p>
+    <img src="/docs-static/img/how-to-guides/posture-check-block-network-range.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+Click `Save`, then click `Continue` and fill out `Name of the Posture Check` with "Exclude Office subnet”.
+
+After we conclude this step, we are ready to create a policy and assign this posture check. 
+### Create a Policy
+We start by creating a simple policy that will allow access from group `route-users` to group `route-nodes`.
+This is needed to establish the connection between the users and the routing peer.
+
+Navigate to the `Access Control -> Policies` section in the NetBird dashboard and click on `Add Policy`.
+
+On the `Source` field, select the group `route-user`, and on the `Destination` field, select the group `route-nodes`.
+Choose `UDP` for the protocol and type `1`on Ports. Click `Continue`.
+<Note>
+    Note that the protocol and port are arbitrary and can be changed according to your needs. An usual choice is to allow ICMP traffic for troubleshooting purposes.
+</Note>
+<p>
+    <img src="/docs-static/img/how-to-guides/policy-office-subnet-with-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+In this step, we'll click `Browse Checks` and select the posture check we created earlier, `Exclude Office subnet`.
+
+Click `Add Posture Checks` and then click `Continue`.
+<p>
+    <img src="/docs-static/img/how-to-guides/policy-with-network-posturecheck-added.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+Give your policy the name "Allow users to route-nodes" and click on `Add Policy`.
+
+We are now ready for the final step of creating the office route.
+
+### Create a Network Route
+
+Now, let's create a [Network Route](https://docs.netbird.io/how-to/routing-traffic-to-private-networks) that will expose the local office subnet `192.168.1.0/24`,
+which will be distributed to all peers members of the group `route-users`. In this example, we will be using a routing peer named `router-01`,
+which is a member of the group `route-nodes`, this way, the policy we just created goes into effect, and all peers from the group `route-users` will be able to reach
+`router-01` only if they are not in the office network, due to our posture check.
+
+To get started navigate to `Network Routes` menu on the NetBird dashboard and click on **Add Route**. Fill out the fields as shown in the image below, and click `Continue`:
+<p>
+    <img src="/docs-static/img/how-to-guides/create-route-with-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+Next assign `route-users` do `Distribution Groups`.
+<p>
+    <img src="/docs-static/img/how-to-guides/distribute-to-groups-posturechecks.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+Click `Continue` and assign the name "Office network access" to `Network Identifier`, click `Continue` agaom and in the final step, finish this process by clicking `Add Route`.
+<p>
+    <img src="/docs-static/img/how-to-guides/route-office-subnet-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+### Testing Posture Check
+Now that we have created the Posture Check, the Policy, and the Network Route, we can test this configuration. In the following example, we will be testing this Posture Check from a macOS client named `client-01`, and as stated earlier, it belongs to the group `route-users`.
+
+#### While connect from inside our office:
+Our local connection shows that we are connected to local office WiFi and and we are part of that subnet.
+<p>
+    <img src="/docs-static/img/how-to-guides/wifi-inside-office-subnet.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+
+When we are connected from inside the office, we can observe that the NetBird route is not available and that the subnet `192.168.1` is using local network interface `en0` to route traffic.
+
+<p>
+    <img src="/docs-static/img/how-to-guides/netbird-routes-list-local.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+
+<p>
+    <img src="/docs-static/img/how-to-guides/netstat-routes-grep-local.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+#### When connected outside the office, we can observe: 
+
+<p>
+    <img src="/docs-static/img/how-to-guides/netbird-routes-list-external.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+
+<p>
+    <img src="/docs-static/img/how-to-guides/netstat-routes-grep-external.png" alt="high-level-dia" className="imagewrapper"/>
+</p>
+
+Notice that subnet `192.168.1.0/24` is routed through our Wireguard interface (`utun100`).
+
+As you can see, the Posture Check is working as expected, and the traffic is being routed through NetBird only when the client is outside the office network.
+This concludes this Posture Check example.

src/pages/how-to/manage-posture-checks.mdx

@@ -142,5 +142,4 @@ Click `Browse Checks` and select the posture check we created earlier, `NetBird
 The `NetBird Version` check will be assigned to the policy. Click `Save Changes` to save the policy updates.
 <p>
     <img src="/docs-static/img/how-to-guides/policy-posture-checks-assigned.png" alt="high-level-dia" className="imagewrapper"/>
-</p>
-
+</p>