[ntp:questions] client behind NAT (low-port bug)

Jason Lixfeld jason-ntp at lixfeld.ca
Sun Apr 15 13:08:42 UTC 2012


Per http://groups.google.com/group/comp.protocols.time.ntp/msg/5a0f45eaecc06578 I checked ntp_proto.c and found that in the latest 4.2.7, the same issue seems to persist as what David was suggesting was the underlying issue.

         * Monitor the packet and get restrictions. Note that the packet
         * length for control and private mode packets must be checked
         * by the service routines. Some restrictions have to be handled
         * later in order to generate a kiss-o'-death packet.
         * Bogus port check is before anything, since it probably
         * reveals a clogging attack.
        if (SRCPORT(&rbufp->recv_srcadr) < NTP_PORT) {
                return;                         /* bogus port */

I'm wondering if there is another fix here?  Do I manually change NTP_PORT above to 0 (not being a programmer by any stretch, not knowing the farther reaching effects of such a change) and recompile?

To circle back around, the main issue here is that the NAT box ahead of my internal NTP server changes the source port of the output NTP request to some low port < 123, which ntpd seems to reject.  Modifying the configuration on my NAT box may be an option as well.  I'm just trying to see where all my bases lie.

I've installed 4.2.7p272, but the issue still seems to be present there too.

As a sample. here's a packet dump from the NTP server affected by the low-port bug where you can see source ports 5 and 14 get no response from the NTP server, but 123 does.

05:40:17.596649 IP > NTPv4, Client, length 48
05:57:23.599748 IP > NTPv4, Client, length 48
06:14:27.599740 IP > NTPv4, Client, length 48
06:14:27.599766 IP > NTPv4, Server, length 48

Thanks in advance.

More information about the questions mailing list