<div dir="ltr"><div>For Linux iptables SNAT (used with --to-source), the default is to change the packet as little as possible.</div><div><br></div><div><a href="https://linux.die.net/man/8/iptables">https://linux.die.net/man/8/iptables</a></div><div>"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. <br></div><div>Where possible, no port 
alteration will
occur."</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div><a href="https://datatracker.ietf.org/doc/html/rfc6335#section-6">https://datatracker.ietf.org/doc/html/rfc6335#section-6</a> is also a good reference.<br></div><div><br></div><div>Alvaro<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 4, 2021 at 10:14 AM Blake Hudson <<a href="mailto:blake@ispn.net">blake@ispn.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Current gen Cisco ASA firewalls have logic so that if the connection <br>
from a private host originated from a privileged source port, the NAT <br>
translation to public IP also uses an unprivileged source port (not <br>
necessarily the same source port though).<br>
<br>
I found out that this behavior can cause issues when you have devices on <br>
your network that implement older DNS libraries or configs using UDP 53 <br>
as a source and destination port for their DNS lookups. Occasionally the <br>
source port gets translated to one that ISC BIND servers have in a <br>
blocklist (chargen, echo, time, and a few others) and the query is <br>
ignored. As I recall, this behavior is hard coded so patching and <br>
recompiling BIND is required to work around it.<br>
<br>
I forget what the older ASA behavior was. It may have been to leave the <br>
source port unchanged through the NAT process (I think this is what you <br>
mean by "not translated"). In that case the client doesn't implement <br>
source port randomization and the NAT doesn't "upgrade" the connection <br>
to a random source port so I don't really see it as an issue. Ideally <br>
the client would implement source port randomization itself so it would <br>
be using source ports within its ephemeral port range for outgoing <br>
connections.<br>
<br>
--Blake<br>
<br>
<br>
On 6/4/2021 7:36 AM, Jean St-Laurent via NANOG wrote:<br>
> 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?<br>
><br>
> What are you trying to achieve?<br>
><br>
> Jean<br>
><br>
> -----Original Message-----<br>
> From: NANOG <nanog-bounces+jean=<a href="mailto:ddostest.me@nanog.org" target="_blank">ddostest.me@nanog.org</a>> On Behalf Of Fernando Gont<br>
> Sent: June 4, 2021 3:00 AM<br>
> To: <a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a><br>
> Subject: NAT devices not translating privileged ports<br>
><br>
> Folks,<br>
><br>
> While discussing port randomization (in the context of <a href="https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt" rel="noreferrer" target="_blank">https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt</a><br>
> ), 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).<br>
><br>
> Any clues/examples of this type of NATs?<br>
><br>
> Thanks!<br>
><br>
> Regards,<br>
> --<br>
> Fernando Gont<br>
> Director of Information Security<br>
> EdgeUno, Inc.<br>
> PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531<br>
><br>
><br>
><br>
><br>
><br>
<br>
</blockquote></div>