All of lore.kernel.org
 help / color / mirror / Atom feed
* First packet NAT flow
@ 2020-12-20 12:14 Rafael Ganascim
  2020-12-21  1:15 ` Florian Westphal
  0 siblings, 1 reply; 3+ messages in thread
From: Rafael Ganascim @ 2020-12-20 12:14 UTC (permalink / raw)
  To: netfilter

Hello guys,

A question about how NAT works within the Linux kernel.

As I understand it, when a connection is already established at
conntrack, the packets use these entries to flow, do the translation,
and don't go through the entire ruleset. Is this reading correct?

But what about the first connection packet that needs to be NATed?
Suppose we have 1000 rules of SRC-NAT, are the first packets covered
all of them until a match occurs? Or is there a structure already
"configured" where the IP can get its NAT IP quickly?
And for example, for 1:1 NAT, despite the number of rules, what's the
difference between 256 rules of src-nat or just one using NETMAP
module?

Warm regards,

Rafael

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: First packet NAT flow
  2020-12-20 12:14 First packet NAT flow Rafael Ganascim
@ 2020-12-21  1:15 ` Florian Westphal
  2020-12-21 11:52   ` Rafael Ganascim
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Westphal @ 2020-12-21  1:15 UTC (permalink / raw)
  To: Rafael Ganascim; +Cc: netfilter

Rafael Ganascim <rganascim@gmail.com> wrote:
> As I understand it, when a connection is already established at
> conntrack, the packets use these entries to flow, do the translation,
> and don't go through the entire ruleset. Is this reading correct?

They skip the NAT table/nat chains, but not the rest of the ruleset.

> But what about the first connection packet that needs to be NATed?
> Suppose we have 1000 rules of SRC-NAT, are the first packets covered
> all of them until a match occurs?

Yes.

> Or is there a structure already
> "configured" where the IP can get its NAT IP quickly?

No.

> And for example, for 1:1 NAT, despite the number of rules, what's the
> difference between 256 rules of src-nat or just one using NETMAP

None.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: First packet NAT flow
  2020-12-21  1:15 ` Florian Westphal
@ 2020-12-21 11:52   ` Rafael Ganascim
  0 siblings, 0 replies; 3+ messages in thread
From: Rafael Ganascim @ 2020-12-21 11:52 UTC (permalink / raw)
  To: Florian Westphal; +Cc: netfilter

Em dom., 20 de dez. de 2020 às 22:15, Florian Westphal <fw@strlen.de> escreveu:
>
> Rafael Ganascim <rganascim@gmail.com> wrote:
> > As I understand it, when a connection is already established at
> > conntrack, the packets use these entries to flow, do the translation,
> > and don't go through the entire ruleset. Is this reading correct?
>
> They skip the NAT table/nat chains, but not the rest of the ruleset.
>
> > But what about the first connection packet that needs to be NATed?
> > Suppose we have 1000 rules of SRC-NAT, are the first packets covered
> > all of them until a match occurs?
>
> Yes.
>
> > Or is there a structure already
> > "configured" where the IP can get its NAT IP quickly?
>
> No.
>
> > And for example, for 1:1 NAT, despite the number of rules, what's the
> > difference between 256 rules of src-nat or just one using NETMAP
>
> None.

Thanks Florian,

And when we have more rules...? For example I have a LSNAT (CGNAT) box
with ~12k rules in the NAT table (with jumps trying to limit the
search range etc - it's working well). Using the NETMAP module I can
translate those rules to a small set of them.
Do we have performance improvements doing it?

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-12-21 11:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-20 12:14 First packet NAT flow Rafael Ganascim
2020-12-21  1:15 ` Florian Westphal
2020-12-21 11:52   ` Rafael Ganascim

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.