Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Dec 2015 17:50:45 +0100 (CET)
From:      elof2@sentor.se
To:        Mark Felder <feld@FreeBSD.org>
Cc:        Matthew Seaman <matthew@FreeBSD.org>,  freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: IPFW blocked my IPv6 NTP traffic
Message-ID:  <alpine.BSF.2.00.1512011734490.54839@farmermaggot.shire.sentor.se>
In-Reply-To: <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com>
References:  <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <565DBA5B.20203@FreeBSD.org> <alpine.BSF.2.00.1512011650350.54839@farmermaggot.shire.sentor.se> <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Dec 2015, Mark Felder wrote:

>
>
> On Tue, Dec 1, 2015, at 09:53, elof2@sentor.se wrote:
>>
>> On Tue, 1 Dec 2015, Matthew Seaman wrote:
>>
>>> On 2015/12/01 15:05, Mark Felder wrote:
>>>> Notice how almost all of them are port 123 on both sides, but a few of
>>>> them are not. Why? The RFC says that NTP is supposed to be using port
>>>> 123 as both the source and destination port, but I clearly have
>>>> something happening on port 16205. Is something screwy with ntpd in
>>>> CURRENT?
>>>
>>> NTP not using port 123 as the source port usually indicates that it is
>>> behind a NAT gateway at the other end.  It's harmless and fairly common.
>>
>> ...or simply that it is a ntp *client* like ntpdate, and not a daemon.
>> Clients often use a random source port, while ntpd use source port 123.
>>
>
> I wouldn't expect something in pool.ntp.org to be behind NAT and this
> wasn't an ntp client like ntpdate, but those are both interesting
> scenarios. Perhaps I'm just naive and they have a good reason for using
> NAT in front of that NTP server.

Not that this helps this thread to move on, but just to clarify:

In this case, the NAT that would introduce the randomized src port would 
be *your* NAT, not a NAT at pool.ntp.org.


Deny UDP [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0

The blocked response came from port 123 just as expected.

If the client truly sent out a query from src port 123, then it must have 
been your NAT that picked a free random port to use for its outgoing 
connection, i.e. port 58285.
The server then respond back to your NAT-IP 2001:470:1f11:1e8::2 at port 
58285.
Your NAT should receive the packet, match it against its NAT table, find
that it has indeed an ongoing UDP connection for that particular flow, so 
it rewrites the dst IP and dst port to your original internal IP address 
and original port (123) and send it back to the client.

/Elof



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1512011734490.54839>