From 5be02a34fbdb908c452e6a42de121996a1da34b6 Mon Sep 17 00:00:00 2001 From: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com> Date: Wed, 13 May 2026 12:34:21 +0200 Subject: [PATCH] docs(site-to-vpn): drop Source IP Behavior section The "Outbound SNAT requirement" section already covers why the source IP ends up as the routing peer's NetBird IP; a separate Source IP Behavior section was repeating the same point and adding a speculative paragraph about future Networks support. Drop both, plus the up-front Warning that pointed at the removed section. --- .../use-cases/by-scenario/site-to-vpn.mdx | 20 ------------------- 1 file changed, 20 deletions(-) diff --git a/src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx b/src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx index 79ae8684..0a9e85de 100644 --- a/src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx +++ b/src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx @@ -39,12 +39,6 @@ upstream firewall. Without this, the overlay peer drops the traffic at its access control. See [Outbound SNAT requirement](#outbound-snat-requirement). - -The overlay peer will always observe the **routing peer's NetBird IP** as -the source of the request, not the clientless device's local IP. See -[Source IP Behavior](#source-ip-behavior) below for the details. - - ## Prerequisites - A [NetBird cloud account](https://app.netbird.io/) or [self-hosted instance](/selfhosted/selfhosted-quickstart) @@ -306,20 +300,6 @@ its upstream firewall), as shown in Step 3. This is a real, observable limitation rather than a quirk: without the SNAT, the dashboard masquerade flag has no effect on the wire. -## Source IP Behavior - -Because of the outbound SNAT above, the target peer always observes the -**routing peer's NetBird IP** as the source — regardless of which clientless -device on the site initiated the connection. - -Preserving the original site source IP all the way to the target peer is -**not currently possible**. Removing the access policy that targets the -destination peer does not "open" it; it simply tears down the wireguard -pairing between the routing peer and the destination, and the connection -fails to establish at all. Future versions of [Networks](/manage/networks) -may expose Resource groups as policy sources for the Site-to-VPN direction -— track the Networks documentation for updates. - ## Troubleshooting **Connection times out from the clientless device.**