|
| 1 | +# Networks access management |
| 2 | + |
| 3 | +To manage access to and through the Routing Peers in Networks it is essential to understand that in the |
| 4 | +standard operating system networking model IP addresses assigned directly to the device are handled differently and |
| 5 | +independently of addresses behind it (aka routed/forwarded addresses). |
| 6 | +This currently also holds true in context of NetBird's Networks and Routing Peers access management: |
| 7 | + |
| 8 | +- IP address attached directly to any of the client's local interfaces is NOT considered being routed/forwarded |
| 9 | + and is policed by the device's rules. In context of NetBird those are the Access Policies naming any of |
| 10 | + the Routing Peer's Groups as the destination: |
| 11 | + - this holds true especially when the address overlaps with the routed network's range, |
| 12 | +- all the other IP addresses from the network range are considered being routed/forwarded and are governed by separate |
| 13 | + set of rules. In NetBird context |
| 14 | + |
| 15 | +## General rules |
| 16 | + |
| 17 | +Here are some general rules resulting from above mechanism: |
| 18 | + |
| 19 | +- access to **Resources** does not require access to the **Routing Peer** itself, |
| 20 | + - the Resource's Group needs to be mentioned in Access Policy's destination explicitly: |
| 21 | + - `All` Group does not cover Resources, unless it is explicitly assigned to those, |
| 22 | + - it is generally advised not to use the `All` group in the context of Networks, |
| 23 | +- access to the **Routing Peer**'s local IP address needs to be explicitly allowed: |
| 24 | + - granting access to Resource will establish connectivity to the Routing Peer (eg: in `netbird status -d`), but |
| 25 | + traffic destined to any of the Routing Peer's local IP addresses will be rejected, |
| 26 | +- the Resource policy can have completely different scope than the Routing Peer policy, |
| 27 | + - access to the Routing Peer is not limited by the Resource policies in any way, |
| 28 | + - it is possible to grant broader or more restricted access to the Routing Peer's IP address |
| 29 | + than to the rest of the routed network, |
| 30 | +- you can access _inactive_ Routing Peers on the same Network by their "local" IP addresses, because they are now |
| 31 | + effectively remote Resource, |
| 32 | +- domain-based (as opposed to subnet-based) Resources still resolve to and create routes for a set of one or |
| 33 | + more IP addresses (`/32` subnets), which in turn conform to the same rules and need to be planned accordingly: |
| 34 | + - if it happens to resolve to the IP address of the Routing Peer it will need to be allowed by a policy mentioning |
| 35 | + Routing Peers as destination, |
| 36 | + |
| 37 | +## Visualising access |
| 38 | + |
| 39 | +Following diagram explains the differences visually, it depicts: |
| 40 | + |
| 41 | +- 1 User's laptop running NetBird client, |
| 42 | +- 3 Routing Peers running NetBird client, |
| 43 | +- a single LAN server, which does not run NetBird, |
| 44 | +- Network Resource routing the `192.168.1.0/24` network, |
| 45 | +- set of green dashed lines representing connections governed by the Access Policy |
| 46 | + granting access to the Resource, |
| 47 | +- set of orange solid lines representing connections governed by the Access Policy |
| 48 | + granting access directly to the Routing Peer, |
| 49 | + |
| 50 | +<p> |
| 51 | + <img src="/docs-static/img/how-to-guides/routing-peer-policies.drawio.png" alt="routing-peer-policies" className="imagewrapper-big"/> |
| 52 | +</p> |
| 53 | + |
| 54 | + |
| 55 | +In practice, you might observe seemingly "random" results depending on which Peer is |
| 56 | +currently handling your requests. |
| 57 | + |
| 58 | +### Example: access granted only to the Resource |
| 59 | + |
| 60 | +Having a single policy allowing access to Resources, but not to the Routing Peer would result in following behaviors: |
| 61 | + |
| 62 | +- connecting through `router-1` you will be able to access the`192.168.1.0/24` subnet |
| 63 | + except for a single IP `192.168.1.1`(Routing Peer's local address), |
| 64 | +- connecting through `router-2` you won't be able to access `192.168.1.2`, |
| 65 | +- connecting through `router-3` you won't be able to access `192.168.1.3`, |
| 66 | + |
| 67 | +### Example: restrictive Resource access combined with permissive Routing Peer access |
| 68 | + |
| 69 | +Having a Resource policy scoped to ICMP and a Routing Peer policy scoped to TCP 443 (HTTPS) would result in following |
| 70 | +behaviors: |
| 71 | + |
| 72 | +- connecting through `router-1` you will be able to ping (and nothing else) the `192.168.1.0/24` subnet |
| 73 | + except for a single IP `192.168.1.1`. You will not be able to ping it, but instead you will be able to |
| 74 | + access all of HTTPS services running on this specific Routing Peer, |
| 75 | +- connecting through `router-2` you won't be able to ping `192.168.1.2`, but will be able to access HTTPS services, |
| 76 | +- connecting through `router-3` you won't be able to ping `192.168.1.3`, but will be able to access HTTPS services, |
| 77 | + |
| 78 | +### Security caveats |
| 79 | + |
| 80 | +Combining very restrictive Resource policies with broad Routing Peer policies might result in what some users |
| 81 | +would at the first glance consider security vulnerabilities. |
| 82 | + |
| 83 | +This can be particularly unexpected when the Routing Peer is handling multiple subnets with different Groups or |
| 84 | +permission levels assigned. Granting access to the Routing Peer will grant access to all the services running |
| 85 | +on the Routing Peer itself for all the routed subnets, even if one (or all) of the subnets have very |
| 86 | +restrictive/harmless Resource policies in place: |
| 87 | + |
| 88 | +- a potentially harmless Resource policy will make it advertised to the clients, without granting any meaningful access, |
| 89 | +- a permissive Routing Peer policy can grant _full_ access to the IP address from the routed network, |
| 90 | + |
| 91 | +By combining above two policies seemingly unrelated policies and harmless policies, |
| 92 | +you can unexpectedly grant complete access to the Routing Peer's local IP address: |
| 93 | + |
| 94 | +- if you omitted the Resource policy, the route would not be advertised and therefore never be allowed to pass through |
| 95 | + the WireGuard connection, |
| 96 | +- if you omitted the Routing Peer policy, you would not be able to access that single IP address at all, |
0 commit comments