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@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
I believe all devices will translate a privileged ports, but it won't
On 6/4/2021 7:36 AM, Jean St-Laurent via NANOG wrote: 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@nanog.org> On Behalf Of
Sent: June 4, 2021 3:00 AM To: nanog@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
Fernando Gont 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