Fully proxy an internal IP via a Netbird client? (Similar to Tailscale `TS_DEST_IP`)
Hey ๐ Does anyone know if Netbird supports a similar function to TS_DEST_IP in Tailscale (docs)? I'm looking to maybe switch, but that's a feature I'm using and I find it useful as I can expose an internal resource with a Netbird IP address without installing Netbird directly on it.
Tailscale
Using Tailscale with Docker ยท Tailscale Docs
Connect your container to Tailscale using Tailscale's official Docker image.
Solution:Jump to solution
This seems to work, but I'm a bit scared it might break down, either because Netbird will do some things to the iptables periodically, or because a future update of Netbird might break it.
```yaml
- image: netbirdio/netbird:latest
name: netbird...
22 Replies
So just to confirm
Simplifying the IP schemes a bit just as an example, but you mean a setup like this?
Where someone goes to the website at 12.34.56.78, and that VPS redirects it to the 192.168.0.5x server that is there? What type of traffic is it?

If I understand this right diagram right, the "VPN Gateway" machine would be working as a router to forward traffic for e.g. the
192.168.0.0/24
CIDR?
I.e. if I'm in the Netbird VPN, and I want to access Website 1, I need to dial 192.168.0.50
A Router is just a "Computer that routes traffic between interfaces". Windows/Linux/BSD can all do it, so it would just need to be a VM, not an entire router.
If I got that right, it's not quite what I'm looking for
but it could be a router
Ok I meant a "routing peer" as per the Netbird docs
Yes, you would tell the public VPS that the traffic at 192.168.0.0/24 is accessible through the VM at netbird address 100.x.x.1
So anything going to that VPS(or wherever you want that machine, could be your computer) can access the 192.168.x.x network
What I have with Tailscale at the moment is that there is a Tailscale client running for each thing that I want to expose, and it forwards traffic for exactly one IP. The benefit of that that I want to replicate in Netbird is that you mask the internal IP with a Tailscale IP

Maybe this clarifies that ^
(The current setup is
sed /Netbird/Tailscale/g
)So NAT
When something hits 100.x.x.2, NAT to internal Address (hostname of the k8s container)
Yes!
Im hoping someone with k8s experience will have a look, but I would just run a single sidecar that goes to a reverse proxy, and have the reverse proxy be what directs the traffic to the correct site(unless you need them segregated because they are different clients or whatever)
Then you can point all your DNS at a single IP(the proxy), and it should redirect to the correct site.
if not that, then i think you would have to do NAT on the sidecar itself, which im not sure about how to go doing.
I could be wrong, im going by here for the k8s references
https://docs.netbird.io/how-to/kubernetes-operator#expose-kubernetes-services-to-net-bird-network
And i think(but am not sure) it would add the route/network?
Yes, that's how I understand the Netbird operator works. I'd very much like to keep the cluster CIDR "hidden", we have a couple of clusters and it's not entirely impossible two services on two different clusters end up having the same IP. Assigning distinct CIDRs for each cluster is possible, but an in my mind a solution that comes with way too much headache (esp. since changing the CIDR after the fact is not possible and you need to recreate the cluster).
Thanks for your help so far ๐
I think I just found the feature I was looking for. It's called "setup keys" and it's supported by the Netbird operator
But can also be manually configured without the operator:
As far as I can tell it doesn't allow specifying a destination other than the localhost, so it's not quite equivalent to
TS_DEST_IP
, and I suppose it is more akin to having a normal Netbird client installed in the Pod.
That gets me almost there, unfortunately I do have a similar use case where I can't simply inject a sidecar container
Oh and I realized, I'd much rather be exposing a Kubernetes service than an individual Pod this way ๐คSolution
This seems to work, but I'm a bit scared it might break down, either because Netbird will do some things to the iptables periodically, or because a future update of Netbird might break it.
does netbird touch the firewall?
i think it just does routes
and DNS if systemd-resolved
There are Netbird-specific chains in
iptables
, in the container at least