Re: [Sheflug] How NAT Works

[Robin Wood <robin@xxxxxxxxxxxxxxxxxxxxx>]

John
I've just talked to a friend and we worked out that I'm thinking about
symmetric NAT which doesn't work with the basic, poke a hole out and let
anything back in through it, model.

Things make more sense now, the basic version will fail in my locked down
world, but there are setups that aren't as locked down where it does work.

Robin

On Thu, 9 Jan 2025 at 07:07, Robin Wood <robin@xxxxxxxxxxxxxxxxxxxxx> wrote:

> Guess I'll just have to write code, play and see what happens.
>
> On Wed, 8 Jan 2025, 23:36 John Southern, <linuxtarragon@xxxxxxxxx> wrote:
>
>> Hi Robin,
>>
>> I am afraid I do not know either, which is the most common or how I would
>> go about identifying.
>>
>> Regards
>> John
>>
>> On Wed, 8 Jan 2025 at 22:28, Robin Wood <robin@xxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>>
>> > Which is the most common? Is there an easy way to tell? I want to try to
>> > mock this up to see if I can get traffic going through my pfsense box.
>> >
>> > Robin
>> >
>> > On Wed, 8 Jan 2025, 22:21 John Southern, <linuxtarragon@xxxxxxxxx>
>> wrote:
>> >
>> > > The Picky NAT does change the port depending on the source. The easy
>> NAT
>> > > keeps it open no matter what source IP is used.
>> > >
>> > > John
>> > >
>> > > On Wed, 8 Jan 2025 at 22:18, Robin Wood <robin@xxxxxxxxxxxxxxxxxxxxx>
>> > > wrote:
>> > >
>> > > > I've got as far as the birthday problem so I might just need to read
>> > some
>> > > > more.
>> > > >
>> > > > Does Picky NAT not care what IP the traffic is coming from? The
>> port is
>> > > > just open for a short period of time for any connections? That seems
>> > > quite
>> > > > dangerous.
>> > > >
>> > > > Robin
>> > > >
>> > > > On Wed, 8 Jan 2025, 22:13 John Southern, <linuxtarragon@xxxxxxxxx>
>> > > wrote:
>> > > >
>> > > > > 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
>> > > > >
>> > > > _______________________________________________
>> > > > 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
>> >
>> _______________________________________________
>> 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