NAT devices not translating privileged ports

Sat Jun 5 18:54:50 UTC 2021

For Linux iptables SNAT (used with --to-source), the default is to change
the packet as little as possible.

https://linux.die.net/man/8/iptables
"If no port range is specified, then source ports below 512 will be mapped
to other ports below 512: those between 512 and 1023 inclusive will be
mapped to ports below 1024, and other ports will be mapped to 1024 or
above.
Where possible, no port alteration will occur."

So, if there are no "collisions", the same src port will be used. If there
are "collisions" (multiple flows with the same src port and dst IP/port),
then another src port within its "range" will be used.

But it can be configured, for example, to use ports 1024-65535, in which
case flows with src port < 1024 will endup using ports > 1024 after they
are NATed.

https://datatracker.ietf.org/doc/html/rfc6335#section-6 is also a good
reference.

Alvaro

On Fri, Jun 4, 2021 at 10:14 AM Blake Hudson <blake at ispn.net> wrote:

> Current gen Cisco ASA firewalls have logic so that if the connection
> from a private host originated from a privileged source port, the NAT
> translation to public IP also uses an unprivileged source port (not
> necessarily the same source port though).
>
> I found out that this behavior can cause issues when you have devices on
> your network that implement older DNS libraries or configs using UDP 53
> as a source and destination port for their DNS lookups. Occasionally the
> source port gets translated to one that ISC BIND servers have in a
> blocklist (chargen, echo, time, and a few others) and the query is
> ignored. As I recall, this behavior is hard coded so patching and
> recompiling BIND is required to work around it.
>
> I forget what the older ASA behavior was. It may have been to leave the
> source port unchanged through the NAT process (I think this is what you
> mean by "not translated"). In that case the client doesn't implement
> source port randomization and the NAT doesn't "upgrade" the connection
> to a random source port so I don't really see it as an issue. Ideally
> the client would implement source port randomization itself so it would
> be using source ports within its ephemeral port range for outgoing
> connections.
>
> --Blake
>
>
> On 6/4/2021 7:36 AM, Jean St-Laurent via NANOG wrote:
> > I believe all devices will translate a privileged ports, but it won't
> translate to the same number on the other side. It will translate to an
> unprivileged port. Is it what you meant or really there are some devices
> that will not translate at all a privileged port?
> >
> > What are you trying to achieve?
> >
> > Jean
> >
> > -----Original Message-----
> > From: NANOG <nanog-bounces+jean=ddostest.me at nanog.org> On Behalf Of
> Fernando Gont
> > Sent: June 4, 2021 3:00 AM
> > To: nanog at nanog.org
> > Subject: NAT devices not translating privileged ports
> >
> > Folks,
> >
> > While discussing port randomization (in the context of
> https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
> > ), it has been raised to us that some NAT devices do not translate the
> source port if the source port is a privileged port (<1024).
> >
> > Any clues/examples of this type of NATs?
> >
> > Thanks!
> >
> > Regards,
> > --
> > Fernando Gont
> > Director of Information Security
> > EdgeUno, Inc.
> > PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210605/481b367b/attachment.html>