Re: [Sheflug] How NAT Works

[John Southern <linuxtarragon@xxxxxxxxx>]

Hi Robin,

My understanding is you send out to the STUN server and your NATTing router
keeps that port linked back to your client1 for a short period.
In that time client 2 can send info to it and get through.

In your scenario you are using the Picky NAT where the port it gives when
talking to the STUN server is different to the port it would want to use
from client2.
That is where the article then jumps down to the Birthday problem if one of
the NAT devices is an Easy NAT or having to use one of the three protocols
(UPnP-IGD, NAT-PMP or PCP) to find the port number if they are both HardNAT
devices and so not have to go via the TURN relay for all traffic.

I think a TURN server is more likely to enable a connection but then has to
be able to handle all the traffic thrown at it. I think in Tailscales
situation they are saying that by using all the tricks, they can avoid
having TURN servers in most cases.

There are also TURNS servers for TCP traffic.

Regards
John

On Wed, 8 Jan 2025 at 21:34, Robin Wood <robin@xxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi
> I've read through most of this and I'm stuck on how STUN works. I think I
> must be missing something but this is where I'm having problems.
>
> A NAT device handles connections by quads of source IP and port, and
> destination IP and port. So the client on the inside of my network
> (client1) makes a call out to the STUN server, that records the external IP
> and port the connection is coming from and is then able to pass it on to
> the other side of the connection (client2).
>
> But, if client2 tries to connect to client1 using that IP and port the NAT
> box will see a different source IP, one that doesn't match any that it
> knows, so it would just drop the traffic.
>
> I know the idea is that once client1 has punched out of the NAT, the hole
> is open so the other side is able to send packets back, but I can only see
> that working when the other side is using the same IP as client1 started
> talking to. If client2 tries to talk to the external IP and port client1
> used to talk to the STUN server it shouldn't work.
>
> Is this the failing that TURN is used to handle? If so, then isn't STUN
> dead in most situations? I'd imagine a lot of clients, especially VOIP, are
> behind at least one layer of NAT.
>
> To have written such a big article on STUN, it feels like I've missed
> something important that means it will work in a lot more situations, but I
> can't see what it is. Can anyone explain?
>
> Robin
>
> On Sun, 5 Jan 2025 at 11:56, Richard Ibbotson <richard@xxxxxxxxxxxxxx>
> wrote:
>
> > Hi
> >
> > https://tailscale.com/blog/how-nat-traversal-works
> >
> >
> > Might interest someone out there. How NAT works.
> >
> > --
> > Richard
> >
> >
> > _______________________________________________
> > Sheffield Linux User's Group
> > http://sheflug.org.uk/mailman/listinfo/sheflug_sheflug.org.uk
> > FAQ at: http://www.sheflug.org.uk/mailfaq.html
> >
> > GNU - The Choice of a Complete Generation
> >
> _______________________________________________
> Sheffield Linux User's Group
> http://sheflug.org.uk/mailman/listinfo/sheflug_sheflug.org.uk
> FAQ at: http://www.sheflug.org.uk/mailfaq.html
>
> GNU - The Choice of a Complete Generation
>
_______________________________________________
Sheffield Linux User's Group
http://sheflug.org.uk/mailman/listinfo/sheflug_sheflug.org.uk
FAQ at: http://www.sheflug.org.uk/mailfaq.html

GNU - The Choice of a Complete Generation