Follow

FWIW, we (pre-)released a new piece of TURN server software today:

eturnal.net

@holger great!

We should incorporate finally STUN/TURN in Xash, don't you think, @mittorn?
@a1batross @holger do you mean original stun protocol or some stun-like? stun server need to bind all external udp ports for port-based nat
@a1batross @holger so we need external stun service. Or one more external ipv4

@mittorn @a1batross Short story: There's usually not much point in binding STUN servers to multiple IP addresses these days.

@mittorn @a1batross Long story: The main purpose of STUN is to let a client that sits behind a NAT figure out its public IP address. Usually with the goal of establishing a p2p connection with another client. This will often work, but not under all circumstances: There are NAT types where the client's public IP address depends on the target IP address. So the external IP address as seen by the STUN server might be different from the external IP address the peer's client could talk to.

@mittorn @a1batross Therefore, the "classic" STUN RFC (3489) had the idea of binding the STUN server to two or more addresses in order to let the client figure out to the NAT type: The client perfoms STUN queries against different STUN server addresses and if the responses differ, things look bad.

@mittorn @a1batross One problem with this NAT behavior check is that it's not reliable: If the STUN queries return the same external IP address, the client still cannot be sure the same address would also be used for connections from/to the peer's client. Another problem is that there's simply not much point in determining the NAT type beforehand, even if the check was reliable. Either STUN works or it doesn't, in which case you typically want to fall back to TURN.

@mittorn @a1batross So modern clients usually just perform a single STUN request, let the peer try to connect to the returned address, and fall back to TURN if that fails. Therefore, the NAT behavior check was removed from the newer STUN RFC (5349). There's a separate RFC (5780) which brings it back as an add-on, but it doesn't solve the problems (it just acknowledges them), and I don't think it's being used much.

@holger @a1batross
I am talking not about several stun/turn servers on different IPs, but about detecting external port. We need send packet to same port with port, opened from peer, so server must receive packets on all ports. So we need separate IP for stun/turn and for masterserver (or use lower port that not used for NAT masking)
Sign in to participate in the conversation
\m/ Metalhead.club \m/

Metalhead.club is a Mastodon instance hosted in Germany and powered by 100% green energy.