diff --git a/public/docs-static/img/how-to-guides/routing-peer-policies.drawio b/public/docs-static/img/how-to-guides/routing-peer-policies.drawio
new file mode 100644
index 00000000..316cf502
--- /dev/null
+++ b/public/docs-static/img/how-to-guides/routing-peer-policies.drawio
@@ -0,0 +1,134 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/public/docs-static/img/how-to-guides/routing-peer-policies.drawio.png b/public/docs-static/img/how-to-guides/routing-peer-policies.drawio.png
new file mode 100644
index 00000000..e82e461c
Binary files /dev/null and b/public/docs-static/img/how-to-guides/routing-peer-policies.drawio.png differ
diff --git a/src/pages/how-to/networks.mdx b/src/pages/how-to/networks.mdx
index 230353de..d611380a 100644
--- a/src/pages/how-to/networks.mdx
+++ b/src/pages/how-to/networks.mdx
@@ -73,6 +73,28 @@ See the example below with a policy that allows the group `Berlin Office` to acc
Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior.
+### Managing access to and through the Routing Peers
+
+Routing Peer's local IP address is managed in line with the standard Operating System network access management.
+Access to Resources accessible from _behind_ the Routing Peer is managed independently of the access to the services
+running _directly on_ the Routing Peer, even if the locally assigned IP address overlaps with the routed network range.
+
+This means:
+- you might observe seemingly "random" results depending on which Peer is forwarding your requests,
+- access to **Resources** does not require access to the Routing Peer itself,
+- access to the Routing Peer's local IP address needs to be explicitly allowed:
+ - granting access to Resource will establish connectivity to the Routing Peer (eg: in `netbird status -d`), but
+ traffic destined to any of the Routing Peer's local IP addresses will be rejected,
+- you can access _inactive_ Routing Peers on the same Network by their "local" IP addresses, because they are now
+ effectively remote,
+
+Following diagram explains the differences visually with orange/green color denoting Access Policies governing
+the specific connections:
+
+
+ 
+
+
## Enable DNS wildcard routing
When you configure wildcard domains as resources, you need to enable DNS wildcard routing. Which has an additional effect in comparison to the previous DNS routes behavior from Network routes; it switches the DNS resolution to the routing peer instead of the local client system.
This is also useful for regular DNS routes when you want to resolve the domain names using the routing peer's IP infrastructure, which will allow for more restricted access control rules in newer versions of the clients (**1**) and for the traffic to go to a near routing peer service.