Redirect all NTP traffic to internal IP

[demux]

In a first step I let run ntpdate for about 12h every 5 secs from pfsense to the ntp server. I recorded a tcpdump on both ends and I had not one missed ntp packet. Meanwhile ntpd had the usual problems. Really strange. In the logs of doing the ntpq -p against the pfsense machine (every 7 seconds) I saw that not only my local servers seen from pfsense do experience timeouts, the external servers also have timeouts but less often. Strange...

[johnpoz]

@demux said in Redirect all NTP traffic to internal IP:

I had not one missed ntp packet.

But what did the data say, you can't just look for a reply but what was in the reply.

And what do you mean by nat - there should be no nat to anything local

[demux]

@johnpoz I meant NAT / port forward.
I did not dig into the packets or assemble them. This is why I used ntpdate and ntpq -p.
I assume ntpdate and ntpq will tell me if there is something unusual inside the packets.
If ntpdate reports increasing times by 5 secs if called every 5 secs, then I assume it's ok.
If I see packets travelling from left to right and back and a resuling answer by ntpdate, I assume it is ok. And I had run ntpq -p against pfsense to see what the pfsense ntp server currently does.
So I see an uninterrupted data flow and data that makes sense to ntpdate (and to me).
Do you know what version of ntpd was included in version 2.4.3?

[johnpoz]

Again what would port forwarding have to do with pfsense talking to your local NTP server? There is no nat from pfsense IP to some device on one of pfsense networks.

No I do not... Look in the release notes.. 2.4.4p2 is current
ntpq 4.2.8p12@1.3728-o Wed Sep 5 02:13:06 UTC 2018 (1)

this version came out well after 2.4.3 so yeah it was a slightly older version.

[demux]

I did a packet trace. What I see is - I believe - strange:
11:22:12.477255 IP (tos 0xb8, ttl 64, id 11111, offset 0, flags [none], proto UDP (17), length 76)
10.200.100.pfSense.123 > 10.200.100.ntp_server.123: [udp sum ok] NTPv4, length 48
Client, Leap indicator: (0), Stratum 2 (secondary reference), poll 5 (32s), precision -22
Root Delay: 0.025558, Root dispersion: 0.500915, Reference-ID: 130.149.17.21
Reference Timestamp: 3759301270.497451600 (2019/02/16 11:21:10)
Originator Timestamp: 3759301236.436497210 (2019/02/16 11:20:36)
Receive Timestamp: 3759301236.437431054 (2019/02/16 11:20:36)
Transmit Timestamp: 3759301332.477197054 (2019/02/16 11:22:12)
Originator - Receive Timestamp: +0.000933844
Originator - Transmit Timestamp: +96.040699843
11:22:12.477621 IP (tos 0xb8, ttl 64, id 20383, offset 0, flags [DF], proto UDP (17), length 76)
10.200.100.ntp_server.123 > 10.200.100.pfSense.123: [udp sum ok] NTPv4, length 48
Server, Leap indicator: (0), Stratum 1 (primary reference), poll 5 (32s), precision -23
Root Delay: 0.000000, Root dispersion: 0.550033, Reference-ID: DCFb
Reference Timestamp: 3759301329.370467552 (2019/02/16 11:22:09)
Originator Timestamp: 3759301332.477197054 (2019/02/16 11:22:12)
Receive Timestamp: 3759301332.475587226 (2019/02/16 11:22:12)
Transmit Timestamp: 3759301332.475714633 (2019/02/16 11:22:12)
Originator - Receive Timestamp: -0.001609827
Originator - Transmit Timestamp: -0.001482420

As far as I understood, the first packet leaving the client should have (nearly) Originator=Receive=Transmit. The server uses sets Originator=Originator client, Receive=receive time at the server, Transmit=transmit time at the server.
What does the client (pfSense ntp server) do between Receive and Transmit times?
This is whay I see the correct and fast flow of packets; it seems to hang around in pfSense's ntp server before being sent out.
???

[4o4rh]

Thanks fellas, i got this to work with the above info.
Had to forward to the interface, instead of 127.0.0.1.

Works if set to time.nist.gov option in windows 10, but not time.windows.com
Any ideas why

[johnpoz]

What do you mean doesn't work is set to time.windows? If your doing redirection shouldn't matter what the client asks for.. As long as it would resolve.

[4o4rh]

@johnpoz talking through my bottom. it synchronized. maybe i tried to quick after the gov one...anyways. all good now

[febu]

My crux was that part: NAT Reflection: Disable

Before I had it enabled and had a auto or 2nd LAN rule that was not beneficial for NTP redirect.

With NAT Reflection: Disable the answer time is below 5ms, and I guess the answer is coming from pfsense.

[tinfoilmatt]

@febu This suggestion is only relevant if, under System / Advanced / Firewall & NAT, the system setting "NAT Reflection mode for port forwards" is set to anything other than "disabled" (in which case the individual "NAT reflection" setting you've referred to within a Port Forward redirect rule may override the system setting).

Alternatively you might reconsider the system setting you've configured under System / Advanced / Firewall & NAT / NAT Refelction mode for port forwards.