NAT devices not translating privileged ports
Blake Hudson
blake at ispn.net
Thu Jun 10 14:42:21 UTC 2021
On 6/10/2021 4:04 AM, Fernando Gont wrote:
> Hi, Blake,
>
> Thanks a lot for your comments! In-line....
>
>
> On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson 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).
> Did you actaully mean "...also uses a *privileged port*"?
>
Yes I did. Thanks.
>> 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.
> 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.
>
>
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).
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. _But this statement is true of any one-to-many NAT_.
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).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210610/07aa7f72/attachment.html>
More information about the NANOG
mailing list