To be honest there shouldn't be any nat from firewall when it talks to something on the internet. Pfsense should use the address of the interface it uses to talk to the ntp server. There should be no reason to set any specific outbound nat. Would be an example where pfsense changes the source port.

Look at my sniff see the answers destination port, those are just random ports that ntp used to make the query, yes pfsense changes the source ports when it nats normally.ġ92.168.1.100:55555 -> 1.2.3.4:123 (pfsense) publicIP:42512 -> 1.2.2.4:123 NTP doesn't normally use a source port of 123 anyway. Pfsense auto changes the source port by default. Where in that link does it say to set static port? Huh? That is what pfsense does out of the box, with the normal nat. The outgoing NTP source port for networks where something interferes with incoming traffic on 123/UDP. Upload the packet capture so can see the details of the query and what is in the response, and what was the response time of when you sent your query and when you got an answer.īut that link to outbound natting is not your fix or to do with your problem - because clearly from the reach you are talking to them and getting said in NTP not working: So again - lets see a sniff to one of those IPs your talking to. But clearly you are 177 for example would mean you missed only 1 out of the last 8.īut your jitter -1000, tells me your not getting consistent responses. If your reach was zero - then your not ever getting a response. Your just not getting consistent answers. You don't have a reach of 0, your talking to those servers. So here are the ntp stats for one of those IPs Where is that - your pointing at pools - those are just going to be some random servers out on the internet that are joined into be in the pool.ĭid you setup 0. and 2. to resolve to your own servers? Why would you do that? If your running your own local ntp, then point to them.Īnd again doesn't matter where the ntp servers are, reach that is over 0 tells me your talking to them at some point Both in response time and in actually getting said in NTP not working:Ģ of them are local ntp servers in my network.

You could watch all your ntp traffic - I jut figured it was easier to see the pattern and the responses with only watching one of them.Īre you over a wifi connection or something? Is your wan saturated or something? For ntp to sync it needs stability in getting responses from where your asking for ntp. If your not seeing something like that where you get 8 responses to your 8 queries in a row, then yeah your never going to reach 377, and response time is all over the board with crazy differences in the response time your going to have almost impossible time getting ntp to sync. Pretty consistent 12 to 15 ms in the response, etc.

The poll is 64 seconds, see how it goes out roughly like every 64 seconds, and then a response a few ms later. Here is a sniff to one of the ntp servers I have set as backup on my ntp server I run locally, which is doing pps with a gps hat, etc And the responses should be fairly consistent in time they take to happen.

Sniff the traffic yourself - you should see your query and your response. Not have a shitty connection? What non 377 reach that is not zero tell you is you send a ntp query and 'sometimes' you get an answer.

Packet tracer ntp status clock insane