NAT traversal

[felinira]

We claim to be hosting a public STUN server in this document:

https://github.com/magic-wormhole/magic-wormhole-protocols/blob/01b7c46ffaec4c12866f99bb2596fd4e49db460a/transit.md#traversing-nat

But alas, this server never got operational.

Would it be possible for us to either implement a custom NAT traversal mechanism into the mailbox server, or else get this STUN server operational in some way?

[meejah]

Unfortunately, some of the protocol docs have "speculative" words in them for things that don't actually exist :(

Sort-term we should remove the reference.

STUN/TURN is ... exceedingly complex. It would be good to have additional ways to get through NATs, but I'm not sure if "just run a STUN server" is really sufficient here (i.e. you need some client support and more protocol work on Transit in to get to the end goal, right?)

Perhaps we can build in this "better NAT traversal answer" for Dilation? (It's not clear to me from a quick look what that section of the document is supposed to describe .. merely knowing your external IP via STUN probably doesn't get you through a NAT, but it doesn't say what clients should do to accomplish this).

I have personally worked on pinhole-punching systems, so it is certainly feasible to do something here, but the details become pretty important.

I don't think the Mailbox server needs to provide anything directly here; hints are exchanged directly between clients (whether those hints are used in the older Transit protocol or the in-development Dilation protocol). What were you thinking the Mailbox server could/would provide?

[piegamesde]

Unfortunately, deploying the STUN server on the magic-wormhole.io domain somehow fell under the bus, the rust implementation still uses the initially temporary server on piegames.de. I'd appreciate if we could migrate that over. The NixOS configuration is merely a couple of lines:

    services.coturn = {
      enable = true;

      # Tailored to the needs of Magic Wormhole relay
      # We only do STUN, no TURN, no security, no authentication
      no-udp = true;
      no-tls = true; # <-- maybe remove that one some time
      no-dtls = true;
      no-cli = true;
      extraConfig = ''
        stun-only
        no-rfc5780
        no-stun-backward-compatibility
      '';
    };
    networking.firewall.allowedTCPPorts = [
      config.services.coturn.listening-port
      config.services.coturn.alt-listening-port
    ];

---

but I'm not sure if "just run a STUN server" is really sufficient here

that's exactly what wormhole-rs does.

Perhaps we can build in this "better NAT traversal answer" for Dilation? (It's not clear to me from a quick look what that section of the document is supposed to describe .. merely knowing your external IP via STUN probably doesn't get you through a NAT, but it doesn't say what clients should do to accomplish this).

This section of the documentation describes a way for sending and handling direct-tcp-v1 hints which can establish a direct connection across most firewalls and NAT setups. I am not aware of any further improvements to be made to the current system which wouldn't require switching over to UDP completely.

Clients can accomplish this by quering their external IP and port and then sending that as hint, while keeping the connection to the STUN server open to recycle it with REUSEADDR. I agree that the wording of the documentation could be improved here to make it more clear.

[felinira]

What were you thinking the Mailbox server could/would provide?

A reimplementation of what STUN does (it's not a lot) to maybe simplify deployment. But I wouldn't mind just running proper STUN instead.

[meejah]

If the only thing required is to reflect the IP address back, that seems a lot less than "full STUN", right?
That could indeed potentially be a Mailbox service.

(There's also services like wtfismyip.com and other less-swear-y options if that is sufficient?)

[piegamesde]

Only for systems without any firewalls. You still need to do the hole punching on top, which requires keeping a connection with a specific port alive and reusing that. (At least on TCP, it could be that for UDP that would be sufficient because no stateful firewall)

[meejah]

but I'm not sure if "just run a STUN server" is really sufficient here

that's exactly what wormhole-rs does.

So you mean that the Rust client code has STUN client behavior, right? (That's what I mean by "just run a STUN server" isn't enough, you need client support too). What happens when talking to a non-Rust client?

[felinira]

Using STUN is completely invisible to the other party, it only increases the chance of establishing a direct connection instead of a connection via the relay server.

[meejah]

I see, so "yes, it needs client support" but also "if any client implementation supports it, the other can benefit (potentially)" right?