Open pomology opened 3 months ago
If your setup is behind another proxy (cloudflare etc) you might need to accept X-Forwarded-For
headers from there to display the real public IP. See https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults
As for
Needless to say, none of my peers can talk to each other, nor ping each other, etc, etc.
Could you please provide a netbird status -dA
from one of the peers? I suspect they are not connecting to each other
Thanks! My server is running on AWS EC2, so not behind any other proxy. Just to be sure, I tried accepting X-Forwarded-For
headers in my Caddyfile, but still got the same result....
Here's a netbird status -dA
for one of the peers:
Peers detail:
ip-172-45-16-167.connect.anon-IbY1H.domain:
NetBird IP: 100.120.11.112
Public key: REDACTED
Status: Disconnected
-- detail --
Connection type:
Direct: false
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Last connection update: -
Last WireGuard handshake: -
Transfer status (received/sent) 0 B/0 B
Quantum resistance: false
Routes: -
Latency: 0s
OS: darwin/arm64
Daemon version: 0.27.5
CLI version: 0.27.5
Management: Connected to https://connect.anon-IbY1H.domain:443
Signal: Connected to https://connect.anon-IbY1H.domain:443
Relays:
[stun:connect.anon-IbY1H.domain:3478] is Unavailable, reason: dial: failed to listen: dial: dial udp: lookup connect.anon-IbY1H.domain: no such host
[turn:connect.anon-IbY1H.domain:3478?transport=udp] is Unavailable, reason: create client: lookup connect.anon-IbY1H.domain: no such host
Nameservers:
FQDN: rmacbook-pro.connect.anon-IbY1H.domain
NetBird IP: 100.120.67.54/16
Interface type: Userspace
Quantum resistance: false
Routes: -
Peers count: 0/1 Connected
Thanks! My server is running on AWS EC2, so not behind any other proxy. Just to be sure, I tried accepting X-Forwarded-For headers in my Caddyfile, but still got the same result....
Do you run a loadbalancer in front (ELB/ALB or some ingress controller)? That would have the same result
Here's a netbird status -dA for one of the peers:
It seems there is some issue with the stun/turn server connection Do you happen to have the same domain for netbird internally as well as for management/signal etc?
So it appears that this only occurs when using Podman. I just now tried rootfull docker instead and the issue goes away, I get correct external IP's that display normally and clients can ping each other. Is Netbird known to be incompatible with Podman? Any idea what's going on?
For testing purposes, I just rebuilt the whole thing with rootless docker, and I get the same issue of an internal IP being shown where the External IP should be, and no communication between peers. It seems these configs simply don't work for operating in a rootless container.
Rootfull containers seem to work fine, but running rootfull is arguably very dangerous.
What do you guys recommend for running rootless? Any recommended configs? Thank you!
Per the below website, it appears this is expected behavior.
https://rootlesscontaine.rs/how-it-works/netns/incoming/
There are apparently ways to get around it, but quite complicated. I hope the devs can work toward as much rootless implementation as possible, to further improve security.
The problem I'm having is that all my peers are getting the very same "Public IP" which is 10.89.1.53. The "Public IP" is actually a private IP, and every single peer gets exactly the same "Public IP" address! Needless to say, none of my peers can talk to each other, nor ping each other, etc, etc.
The peers are on widely geographically dispersed networks, and yet they all have the same problem.
Here is my Caddyfile, from NetBird's default configs:
And here's my compose.yml, again just built on NetBird's default: