41–50 of 80 posts
A self hosted "TURN like" server seems like it would be simpler and more secure -- yet achieve similar goals, and yet still more robust vs funky NAT layers than a dynamic dns solution alone would provide.
Um, no?
> To connect between NATted hosts, you need control of a host that is not Um, no? https://github.com/samyk/pwnat
It clearly works. It's worked for a long time. But the common opinion still seems to be "well, this isn't supposed to work, so using it is a bit dodgy..."
I was hoping this was some kind of stun mechanism for wireguard. No, it's just setting up a cheap wireguard server on AWS. Anyone have anything like an introduction server to help wg peers behind nat find each other?
If it can be, you can just have the NATed peers connect to it, with persistent keep alive set so they maintain it.
> To connect between NATted hosts, you need control of a host that is not Um, no? https://github.com/samyk/pwnat
So we've known about this for years, but does anyone actually rely on this behavior in production, or are we all still pretending that this clever hack could be patched out of existence any day now? It clearly works. It's worked for a long time. But the common opinion still seems to be "well, this isn't supposed to work, so using it is a bit dodgy..."
I've had basically this exact setup running on a cloud server for the past few months. It's pretty liberating to be able to open ports to 10.44.0.0/24 and have all of my different machines easily access them, regardless of what networks they're connected to. I've added in an instance of nsd that manages a zonefile so I can do: ssh laptop.wg.mydomain.net which resolves into 10.44.0.3 for example. There are two major d…
Earlier quoted context omitted.
This[1] is the best post I've seen on that _outside_ of the Tailscale writeup linked below. The clever bit is that the introduction server uses wireguard tunnels to find your endpoint information, then shares it out via DNS. Of course it still requires you to be able to run custom code on all of the endpoints, which requires supporting many different platforms. I'm still looking for a FLOSS mesh network built on top…
I can't see how the post you linked actually does the NAT traversal... Alice finds Bob's external IP:port using the registry. That makes sense. But doesn't Bob need to send a packet to Alice to setup the NAT traversal on his side? More accurately, Alice uses the SRV field to populate the wg peer information on her side -- but how does Bob know that he needs to update the peer information on his side? I think this is…
It assumes full-cone NAT - you punch a hole once by sending a packet to a third party, like a stun server which will along the way tell you your external ip:port, and then a full-cone NAT would forward packets coming to that ip:port back to you, regardless of the source.
If you experience this when logging in to a host via SSH, the delays are almost certainly due to either missing or non-functional forward/reverse DNS (the SSH server will perform these lookups when connections are received).
You've got at least three options (in order of preference):
- Add the appropriate (A/PTR) resource records to DNS so that the queries get a valid response
- Add entries to /etc/hosts file
- Set "UseDNS no" in the /etc/ssh/sshd_config file and add "-u 0" to the parameters passed to `sshd` when it's started (how to do this will vary by distribution/operating system)
Earlier quoted context omitted.
So we've known about this for years, but does anyone actually rely on this behavior in production, or are we all still pretending that this clever hack could be patched out of existence any day now? It clearly works. It's worked for a long time. But the common opinion still seems to be "well, this isn't supposed to work, so using it is a bit dodgy..."
I don't think anybody sane tries to get two machines behind different NATs to talk to each other without the NATs' cooperation in production .
Traversing non-cooperative fully symmetric NATs, which randomize ports, is hard enough also for pwnat. Though in theory should be doable - you just need a lot of patience to brute force ports (there's only 64k of them) until it finally clicks