<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 6/10/2021 4:04 AM, Fernando Gont
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bf96929be9d537b4a980f6f20a42e177cc3d701b.camel@edgeuno.com">
<pre class="moz-quote-pre" wrap="">Hi, Blake,
Thanks a lot for your comments! In-line....
On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Did you actaully mean "...also uses a *privileged port*"?
</pre>
</blockquote>
Yes I did. Thanks.<br>
<br>
<blockquote type="cite"
cite="mid:bf96929be9d537b4a980f6f20a42e177cc3d701b.camel@edgeuno.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The issue would be that if the port is not translated, and multiple
systems in the internal real of the NAT try to use the same privileged
port (say, 123) simultaneously, things wouldn't work.
</pre>
</blockquote>
<br>
Not quite. If multiple devices behind a NAT use SRC=123 & DST =
123 for connections, their connections will still work most of the
time. First, if the connections are to different destinations there
would be no NAT conflict. Second, if the connections occur at
different times, there would be no NAT conflict. Third, if there was
a NAT conflict (meaning connections using the same SRC port, DST
port, and DST host at the same time) the NAT device would see this
and would either adjust the translation to use a different SRC port
(in which case the connection succeeds) or may drop/reject the
connection (in which case the client would eventually retry).<br>
<br>
So saying "things wouldn't work" or "you won't be able to have
multiple NTP clients behind the same firewall" is not true. Saying
that "the number of simultaneous connections is limited" when behind
a NAT would be more accurate. <u>But this statement is true of any
one-to-many NAT</u>. Most NTP clients utilize multiple NTP
servers, often from a pool of available servers, and initiate
connections rather infrequently so I do not expect this to be a
problem in practice unless there are thousands of NTP clients behind
a single NAT accessing a common NTP server (and that NAT does not do
a good job of dealing with collisions).<br>
<br>
I do, however, agree that clients should probably use ephemeral
ports when making any outbound connections as this provides more
entropy for NAT as well as for connection security. This extends to
NTP.<br>
</body>
</html>