NTP Not Working [SOLVED (totally)]



  • EDIT for Solution: Since this thread is long, I'll post the solution to this (thanks, jimp) from the bottom:

    Firewall > NAT, Outbound tab. Add rule to top.

    Disabled: Unchecked
    Do not NAT: Unchecked
    Interface: WAN (make one of these rules for each WAN)
    Protocol: any
    Source: This Firewall (self)
    Destination: any
    Not: Unchecked
    Translation Address: Interface Address
    Port or Range: Blank
    Description: NAT anything out from the firewall itself

    Then either reset the states (Diagnostics > States > Reset States) or reboot the pfSense box (<-- IMPORTANT).

    OP: I just noticed that my devices were not syncing time with the NTP server in pfSense. It was working before, but at some point it seems to have stopped. In pfSense:

    • The NTP Status Dashboard widget has the time, but lists the Sync Source as "No active peers available."
    • Under Status > NTP, all the pools show a status of "Pool Placeholder" and non-pools show "Unreach/Pending." They all have "Stratum" equal to 16 instead of the 1 or 2 they should be, and the "When" fields are all blank (just a dash). All the statistics are 0.
    • Looking at a graph of my NTP statistics, it looks like the last time it was working was back on 05/12/2018.
    • Removing or adding new time servers makes no difference and restarting the NTP service and rebooting pfSense doesn't help.
    • The only packages I have installed are the Netgate Coreboot Upgrade and the OpenVPN Client Export packages (both of which should be irrelevant).
    • EDIT: Under Status > System Logs > NTP, all the log entries are nothing but "Soliciting pool server..." messages.

    I'm at a loss for how to fix this. Any ideas?

    3_1527870657140_20180601 -- pfSense NTP Status.PNG 2_1527870657140_20180601 -- pfSense NTP Server Configuration.PNG 1_1527870657140_20180601 -- pfSense NTP Graph.PNG 0_1527870657139_20180601 -- pfSense Dashboard NTP Status.PNG0_1527871091515_20180601 -- pfSense NTP Log Entries.PNG





  • @gertjan Thanks for the reply. I don't know if you intended to just provide me with a link to a Google Search for "pfsense ntp", but that's what the URL you used:

    https://www.google.com/search?client=firefox-b&ei=hX8RW97XCsu7UZCHqdgI&q=pfsense+ntp&oq=pfsense+ntp&gs_l=psy-ab.3..0j0i22i30k1l9.9122.9610.0.9810.3.3.0.0.0.0.107.288.2j1.3.0....0...1c.1.64.psy-ab..0.3.285....0.6QCTW78GVd8
    

    resolves to. Regardless, I've already done searches and come up with nothing useful. Was there a specific article you were trying to point me to?


  • Rebel Alliance Global Moderator

    Ntp server on pfsense is not going to serve up time to clients if it can not sync time. All the ntp servers your pointing to have 0 for reach.. So no ntp on pfsense is not going to work.

    Looks like you can not reach these servers, even though your resolving them to IP. Maybe your ISP is blocking ntp now?

    Do a simple ntp query to one of the ntp servers in question..

    example

    [2.4.3-RELEASE][root@sg4860.local.lan]/root: ntpdate -q 0.pfsense.pool.ntp.org
    server 108.61.56.35, stratum 2, offset 0.003551, delay 0.05855
    server 50.116.52.97, stratum 2, offset -0.000013, delay 0.05957
    server 69.36.182.57, stratum 2, offset 0.003915, delay 0.05742
    server 141.193.21.6, stratum 2, offset 0.013477, delay 0.09850
    1 Jun 13:32:51 ntpdate[52350]: adjust time server 69.36.182.57 offset 0.003915 sec
    [2.4.3-RELEASE][root@sg4860.local.lan]/root: ntpdate -q pool.ntp.org
    server 192.138.210.214, stratum 2, offset -0.002151, delay 0.06967
    server 45.79.111.114, stratum 2, offset 0.009330, delay 0.09789
    server 74.120.81.219, stratum 3, offset 0.005477, delay 0.06345
    server 34.225.6.20, stratum 2, offset 0.003509, delay 0.05782
    1 Jun 13:33:02 ntpdate[52651]: adjust time server 34.225.6.20 offset 0.003509 sec
    [2.4.3-RELEASE][root@sg4860.local.lan]/root:

    If that is not working then yeah your having an issue talking to the nameservers.



  • @beremonavabi A few more data points. I can ping the pools just fine. Here's one for 0.pfsense.pool.ntp.org:

    PING 0.pfsense.pool.ntp.org (108.61.73.244): 56 data bytes
    64 bytes from 108.61.73.244: icmp_seq=0 ttl=55 time=71.750 ms
    64 bytes from 108.61.73.244: icmp_seq=1 ttl=55 time=71.785 ms
    64 bytes from 108.61.73.244: icmp_seq=2 ttl=55 time=70.744 ms
    
    --- 0.pfsense.pool.ntp.org ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 70.744/71.426/71.785/0.483 ms
    

    And, here's a tracert:

     1  10.4.0.1  12.457 ms  14.250 ms  11.751 ms
     2  199.241.146.177  13.710 ms  12.849 ms  13.194 ms
     3  199.244.116.37  14.318 ms  14.021 ms  46.231 ms
     4  199.244.116.1  12.544 ms  13.587 ms  14.409 ms
     5  173.205.61.21  16.018 ms  15.139 ms  12.568 ms
     6  213.254.230.154  71.582 ms  69.599 ms  70.534 ms
     7  69.31.34.62  73.353 ms  71.083 ms  72.618 ms
     8  * * *
     9  108.61.93.178  72.594 ms  72.036 ms  71.717 ms
    10  108.61.56.35  71.262 ms  70.703 ms  71.341 ms
    

    DNS Lookup also gives a result:

    DNS Lookup
    Hostname 
    0.pfsense.pool.ntp.org
    Results
    Result	Record type
    50.116.52.97	A
    72.5.72.15	A
    154.16.245.246	A
    45.33.48.4	A
    Timings
    Name server	Query time
    127.0.0.1	0 msec
    

    and, DIG:

    Shell Output - dig 0.pfsense.pool.ntp.org
    ; <<>> DiG 9.11.2-P1 <<>> 0.pfsense.pool.ntp.org
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26967
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;0.pfsense.pool.ntp.org.		IN	A
    
    ;; ANSWER SECTION:
    0.pfsense.pool.ntp.org.	47	IN	A	192.138.210.214
    0.pfsense.pool.ntp.org.	47	IN	A	108.59.2.24
    0.pfsense.pool.ntp.org.	47	IN	A	45.33.84.208
    0.pfsense.pool.ntp.org.	47	IN	A	96.244.96.19
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Fri Jun 01 11:42:48 PDT 2018
    ;; MSG SIZE  rcvd: 115
    

    So, it looks like routing-wise, pfSense can handle the traffic to/from these NTP servers. It's just the actual pfSense NTP server that's giving me issues.

    EDIT: I rebooted pfSense again and grabbed the NTP log for just after it started up:

    
    Jun 1 12:05:28	ntpd	47401	Soliciting pool server 69.36.182.57
    Jun 1 12:04:29	ntpd	47401	Soliciting pool server 2001:470:e66b:10::13
    Jun 1 12:04:24	ntpd	47401	Soliciting pool server 216.229.4.69
    Jun 1 12:04:23	ntpd	47401	Soliciting pool server 138.236.128.112
    Jun 1 12:03:22	ntpd	47401	Soliciting pool server 2001:470:5:bf4::14
    Jun 1 12:03:19	ntpd	47401	Soliciting pool server 23.239.26.89
    Jun 1 12:03:17	ntpd	47401	Soliciting pool server 45.76.244.193
    Jun 1 12:02:15	ntpd	47401	Soliciting pool server 2600:1f16:7a3:8a22:a922:8e9c:be3:992a
    Jun 1 12:02:13	ntpd	47401	Soliciting pool server 74.82.59.150
    Jun 1 12:02:13	ntpd	47401	Soliciting pool server 74.207.240.206
    Jun 1 12:01:08	ntpd	47401	Soliciting pool server 2620:6:2000:104::48
    Jun 1 12:01:07	ntpd	47401	Soliciting pool server 96.245.170.99
    Jun 1 12:01:07	ntpd	47401	Soliciting pool server 216.229.0.50
    Jun 1 12:01:06	ntpd	47401	DNS time.nist.gov -> 2610:20:6f96:96::4
    Jun 1 12:01:05	ntpd	47401	0.0.0.0 c016 06 restart
    Jun 1 12:01:05	ntpd	47401	0.0.0.0 c012 02 freq_set kernel -0.581 PPM
    Jun 1 12:01:05	ntpd	47401	0.0.0.0 c01d 0d kern kernel time sync enabled
    Jun 1 12:01:05	ntpd	47401	Listening on routing socket on fd #32 for interface updates
    Jun 1 12:01:05	ntpd	47401	Listen normally on 11 lo0 127.0.0.1:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 10 lo0 [::1]:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 9 igb5 192.168.40.1:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 8 igb5 [fe80::208:a2ff:fe0b:9183%6]:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 7 igb4 192.168.30.1:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 6 igb4 [fe80::208:a2ff:fe0b:9182%5]:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 5 igb3 192.168.20.1:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 4 igb3 [fe80::208:a2ff:fe0b:9181%4]:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 3 igb2 192.168.10.1:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 2 igb2 [fe80::208:a2ff:fe0b:9180%3]:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 1 igb0 192.168.1.1:123
    Jun 1 12:01:05	ntpd	47401	Listen normally on 0 igb0 [fe80::208:a2ff:fe0b:9184%1]:123
    Jun 1 12:01:05	ntpd	47401	proto: precision = 0.370 usec (-21)
    Jun 1 12:01:05	ntpd	47127	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
    Jun 1 12:01:05	ntpd	47127	ntpd 4.2.8p11@1.3728-o Fri Mar 16 18:58:06 UTC 2018 (1): Starting
    

    Nothing leaps out at me as being wrong (except for it soliciting ipv6 addresses when ipv6 is disabled throughout).



  • @johnpoz said in NTP Not Working:

    ntpdate -q 0.pfsense.pool.ntp.org

    Thanks, johnpoz. It looks like our posts crossed in the mist. But, here's the result of the ntpdate command you recommended:

    Shell Output - ntpdate -q 0.pfsense.pool.ntp.org
    server 171.66.97.126, stratum 1, offset -3.122794, delay 0.04608
    server 129.250.35.250, stratum 2, offset -3.123750, delay 0.03802
    server 155.94.164.121, stratum 2, offset -3.121402, delay 0.03841
    server 107.161.30.25, stratum 2, offset -3.120848, delay 0.08383
     1 Jun 11:46:57 ntpdate[17654]: step time server 171.66.97.126 offset -3.122794 sec
    


  • Is pfSense running on a VM inside of a provider network? If so, did you check with them if they are blocking port 123?



  • @cyberzeus No. This is version 2.4.3-Release on my Netgate SG-4860.

    EDIT: I've since updated to 2.4.3-RELEASE-p1 (amd64). As expected, it makes no difference.



  • @beremonavabi Is there any way to force a time update in pfSense? If I'm reading the result of the ntpdate command correctly, my pfSense box is about 3 seconds off from the NTP server time. Could that be too big and pfSense is just refusing to make the change because of that?

    Looking around, I see the following set of commands to do that:

    sudo service ntp stop
    sudo ntpd -gq
    sudo service ntp start
    

    But, I don't know if sudo is needed with pfSense, if it can be done within the GUI, or if it can be done via the console. I don't even know if those are valid things to do in pfSense.

    EDIT: Looks like running ntpdate without a parameter does the job. I ran "ntpdate 0.pfsense.pool.ntp.org" from a Command Prompt in the GUI and it updated the time. But, nothing else has changed. The NTP server is still not grabbing the times from those internet NTP pools.



  • @beremonavabi I think I found a solution. The following thread:

    https://forum.netgate.com/topic/127340/solved-ntpd-on-vlan-sub-interface

    talks about the same problem on vlans. He mentioned:

    "In case WAN is not among the list of the interfaces to listen on, NTPD picks the source ip for it’s outgoing ntp traffic as follows:

    sort the ip addresses where it is configured to listen on (interfaces)
    select the first one as source address
    This ip should have outgoing nat configured.
    As I did not want to have NTPD listen on WAN interface and my vlan sub-interfaces did not have outgoing nat, all ntp traffic leaved the WAN interface with internal ip address as source ip.

    Solution1: select WAN interface to listen on (access from outside is blocked by default)
    Solution2: make sure you have outgoing nat for the interface with lowest ip address."

    I had my WAN un-selected for NTP under Services > NTP. Once I added it, everything started working again. So, something must have changed from when I first configured this (either with the various versions or with my messing around with the settings on my other interfaces).

    Anyway, is there any security implication for letting the NTP server use the WAN? Anything I need to firewall?



  • This post is deleted!

  • Rebel Alliance Global Moderator

    You sure do not need to be listening on wan for it to go outbound and talk to the ntp servers.



  • Maybe you need to check one of the entries as "Prefer"?



  • @johnpoz said in NTP Not Working [SOLVED]:

    You sure do not need to be listening on wan for it to go outbound and talk to the ntp servers.

    Well, that's what I thought when I set it up initially (and it worked that way at the time). But, all I can say is that, at this time (with my current configuration on pfSense 2.4.3-Release), without WAN being selected, the NTP service doesn't work. Merely adding the WAN interface under Services > NTP causes it to immediately start working again.

    EDIT: Another odd thing is that according to that quote I posted from the other thread, above, the other solution is to have the selected interface with the lowest IP address have outbound NAT configured. Well, for me, that's my LAN interface (192.168.1.0.24). Firewall > NAT > Outbound for that interface looks like:

    
    Interface	Source	Source Port	Destination	Destination Port	NAT Address	NAT Port	Static Port	Description	Actions
    		WAN	192.168.1.0/24	*	*	*	WAN address	*		LAN to WAN
    

    So, unless I'm mis-reading that, I do have outbound NAT configured for it. Odd.



  • It's not as simple as you would think. NTP service uses UDP only and there is only one listening socket for sending out queries and listening for replies on UDP port 123. If you set the service not to listen on your WAN interface that will also cut off the service's ability to send anything out on the WAN interface. Yes I know, DNS (for example) does the right thing and uses a separate socket for sending out the queries with a randomized source port, unfortunately NTP hasn't caught up with the new developments yet.



  • So you're saying all my setups with NTP servicing all internal networks but WAN don't work? I must have missed something then...



  • Look at your outbound NAT rules. There should be a rule for outbound NAT'ing anything sourced from 127.0.0.0/8. That is the thing that makes your set up still work if you happen to set the service not to listen on the WAN, the service will instead use the localhost 127.0.0.1 address for the traffic and it will be properly NAT'ed.

    Edit: The service might also select your LAN interface in case WAN is not available and if the LAN interface has a routable IP address it works just fine, also if the LAN IP address is an RFC1918 address you're still good because of the standard outbound NAT.



  • @kpa said in NTP Not Working [SOLVED]:

    Look at your outbound NAT rules. There should be a rule for outbound NAT'ing anything sourced from 127.0.0.0/8. That is the thing that makes your set up still work if you happen to set the service not to listen on the WAN, the service will instead use the localhost 127.0.0.1 address for the traffic and it will be properly NAT'ed.

    Interface	Source	Source Port	Destination	Destination Port	NAT Address	NAT Port	Static Port	Description	Actions
    		WAN	127.0.0.0/8	*	*	*	WAN address	*		Localhost to WAN
    

    I've got that rule, too. But, without WAN being selected for NTP, it still didn't work.


  • Rebel Alliance Global Moderator

    I do not have wan selected, and ntp works just fine to outside ntp servers.

    0_1527950415782_ntpnotlistenwan.png

    And yeah your loopback should be outbound nat.. Unless the user turned off automatic outbound nat then yeah loopback would work and or any of other lan side interfaces. If they turned off loopback nat, pretty sure that would break a bunch of stuff.



  • This post is deleted!


  • Just to double-check this (in case my forcing a clock update in my troubleshooting attempts "fixed" this), I unselected WAN from the selection list on Services > NTP and restarted the NTP service. I was right back in the same situation I was when I started this thread:

    The NTP Status Dashboard widget has the time, but lists the Sync Source as “No active peers available.”

    Under Status > NTP, all the pools show a status of “Pool Placeholder” and non-pools show “Unreach/Pending.” They all have “Stratum” equal to 16 instead of the 1 or 2 they should be, and the “When” fields are all blank (just a dash). All the statistics are 0.
    ...
    Under Status > System Logs > NTP, all the log entries are nothing but “Soliciting pool server…” messages.

    Re-selecting the WAN interface on the list and restarting the NTP service starts everything up properly and everything works again.

    When it's not working, I don't see anything in any of the logs (except for the constant "Soliciting pool server" messages in the NTP log) related to this. Anyone have any suggestions on log settings to try to track this down? I'd really prefer not having NTP listening to the WAN interface if at all possible.



  • So did you check an entry as "Prefer"???



  • @jahonix said in NTP Not Working [SOLVED]:

    So did you check an entry as "Prefer"???

    Yes. It made no difference.



  • @beremonavabi said in NTP Not Working [SOLVED]:

    Was there a specific article you were trying to point me to?

    Wow - I guess I checked in after the storm.
    Indeed, I was using Google myself to find some possible related posts : ntp not being able to contact remote time servers (Firewall and gateway issues).
    Clear is now : there is a something that is not 'default'.
    NTP settings : I haven't checked the WAN interface - only my LAN interfaces (I thought this ensures that ntp is serving my local devices with a time server, my pfSense box). See image below.

    My Outbound NAT is pretty big and pretty default :
    0_1528090393664_7395ac1f-e0ed-427b-b1cb-a93807886403-image.png

    My WAN IP is RFC1918 (192.168.1.10.0/24)
    LAN and OPT1 are default.

    My NTP settings (tghis time with WAN selected - that works also for me ):

    0_1528090777859_2f9b83b6-304e-477f-b01e-e1bffe3b3f37-image.png

    Btw : selecting WAN isn't big deal. As long as there is no firewall rule letting in connections, your ok.
    You should know that the GUI is also listening on ALL interfaces (WAN included !).

    The only thing I changed there was "fr.pool.ntp.org" (I'm living in France) and checked "this is a pool).

    Did you change anything on the Services => NTP => ACLs tab ?



  • On my WAN interface, I'm allowing IP4 UDP traffic going to port 443 (for OpenVPN clients connecting to my OpenVPN server):
    0_1528120985005_20180604 -- Firewall Rules WAN.PNG
    My NTP ACL tab is default: Kiss-o'-death, Modifications, Peer Association, and Trap Service are all checked, while Queries and Service are unchecked.

    EDIT: And since so few of us are having this problem, there's got to be something non-default somewhere that's causing this (as you said). I just can't find it.



  • According to:

    http://support.ntp.org/bin/view/Support/TroubleshootingNTP#Section_9.8.

    ntpd requires full bidirectional access to the privileged UDP port 123

    I assume that's what kpa was referring to, above. So, for those of you who do have NTP synchronizing time correctly without having the WAN interface selected (apparently, most everyone), do you have a firewall rule opening port 123 to UDP traffic on your WAN?

    Also, according to:

    http://support.ntp.org/bin/view/Support/TroubleshootingNTP#Section_9.9.

    there's supposed to be an ntp.conf file at /etc. I don't see that on my SG-4860. Does pfSense use that file for NTP?



  • @beremonavabi said in NTP Not Working [SOLVED]:

    According to:

    http://support.ntp.org/bin/view/Support/TroubleshootingNTP#Section_9.8.

    ntpd requires full bidirectional access to the privileged UDP port 123

    Yep.
    Part "9.8. Check the NTP port" also states :

    Bla bla bla bla ...
    If this is not possible, you may need to run ntpd on the firewall itself, so that it can have full unrestricted access to UDP port >123 in both directions, and then have it serve time to your internal clients. However, this may also be disallowed.

    Of course, our ntpd is running on the firewall pfSense with 'root' privileges, so it can snap to this "123" port, so it can send out requests , and receives the replies.

    I assume that's what kpa was referring to, above. So, for those of you who do have NTP synchronizing time correctly without having the WAN interface selected (apparently, most everyone), do you have a firewall rule opening port 123 to UDP traffic on your WAN?

    No way !!!!
    As seen above, the ntpd process can go outside anytime it wants to do so - connect itself as a "client" to a ntp "server". These connections are outbound.
    Firewall rules on the (WAN) interface are for inbound connection only.
    I have no (well, yes : one : an incoming VPN rule) firewall rules on WAN, so by default no initial connection comes in.
    NTP servers like fr.pool.ntp.org do not connect to my pfSEnse. It's my pfSense that connects to fr.pool.ntp.org.

    Also, according to:
    http://support.ntp.org/bin/view/Support/TroubleshootingNTP#Section_9.9.
    there's supposed to be an ntp.conf file at /etc. I don't see that on my SG-4860. Does pfSense use that file for NTP?

    Yes, no ... this is FreeBSD.
    See your post number 4 here ( you !) told us were we (you !) can find this file ^^
    As you said yourself over there : the file is here : /var/etc/ntpd.conf



  • One more attempt at figuring this out.

    I saw a bug report that was similar (though it involved CARP):

    https://redmine.pfsense.org/issues/5548

    The response was:

    You're breaking NTP connectivity on the backup by sending the traffic using a CARP IP. It won't, and can't, receive those replies - they go to the primary. When WAN isn't bound, it's probably hitting NAT to a CARP IP because it has a private source IP. NAT it to the WAN IP in that case.

    The OP responded:

    Added the following NAT rules at the top of the Outbound manual rules list:
    
    Interfc Source Src Pt Dest Dest Pt NAT Addr NAT Pt Static Description 
    WAN1 This Fw udp/* * udp/123 WAN1 addr * NO NTP to WAN1 INTFC IP 
    

    and that fixed it.

    I was wondering if my restricting all outbound traffic to go through my VPN might be causing a similar problem here. So, I added the following outbound NAT rule (even though it ought to have been covered by my existing NAT rules and I've got "redirect-gateway def1; in my VPN client Custom Options to make sure the firewall, itself, can get out the default interface) which, I think, is an equivalent:

    0_1528665541541_20180610 -- pfSense NTP Fix Question.PNG

    It doesn't make any difference. NTP still won't start without the WAN being selected. Can anyone confirm that these situations might be equivalent and that the NAT rule I added makes some kind of sense?


  • Netgate Administrator

    Can we see your full outbound NAT page?

    Steve




  • Netgate Administrator

    Hmm, looks OK. And you're using manual mode there or hybrid?

    The the WAN the default gateway on your system?

    Is default gateway switching enabled?

    I could imagine NTP trying to use the VPN gateway and sourcing from something not NAT'd there. It should always use the default gateway though.

    Steve



  • @stephenw10 said in NTP Not Working [SOLVED (mostly)]:

    Hmm, looks OK. And you're using manual mode there or hybrid?

    The the WAN the default gateway on your system?

    Is default gateway switching enabled?

    I could imagine NTP trying to use the VPN gateway and sourcing from something not NAT'd there. It should always use the default gateway though.

    Steve

    Manual mode and, yes, the WAN is the default gateway. Default gateway switching is OFF under System > Advanced > Miscellaneous.

    In normal operation, everything is on the VPN_LAN interface (192.168.20.0/24). My firewall rules for that are:

    0_1528726685370_20180611 -- pfSense Firewall Rules VPN_LAN.PNG

    The first two rules are special cases that are hardly ever used. The third rule sends local device traffic to other local devices out the default. And the last rule sends traffic to the outside world out via the VPN's Gateway Group. So, in general, everything to the outside world goes out over the VPN via that Gateway Group. But, I've got "redirect-gateway def1;" in my VPN client Custom Options to make sure the firewall, itself, can still get out the default gateway. I assume NTP falls under that and should get out via the WAN.

    That special Outbound NAT rule with "This Firewall", above, was just a desperate stab at trying to make sure that NTP traffic could get out the WAN and not get stuck by the VPN. But, it didn't work. Assuming I wrote that rule correctly, it doesn't look like that's the issue.

    I wonder if it could be a DNS issue (not being able to resolve the NTP pool names to addresses -- though why adding the WAN to the NTP listening interfaces would "fix" that, I don't know). I'm using DNS Resolver in NON-Forwarding mode. It's active for all my local LAN-type interfaces (not WAN) and sends everything out via the VPNx_WAN interfaces (again, not WAN). I wonder if I should add the WAN to the Outgoing Network Interfaces:

    0_1528727693395_20180611 -- pfSense General DNS Resolver Options.PNG



  • @beremonavabi
    It doesn't look like it's a DNS issue, either. I stuck the actual IP address for a public DNS server

    http://support.ntp.org/bin/view/Servers/PublicTimeServer000011

    in and removed the WAN interface. Same problem: NTP doesn't start. Put the WAN back in the list and all was well.



  • Still not working without WAN selected in Settings > NTP. For posterity, here's some information on my gateways:

    0_1529520307659_20180620 -- pfSense System Routing Gateways.PNG

    RW_VPN is my VPN server, VPNx_WAN are my two VPN clients, IPv6 is off so all the IPV6 gateways are disabled, and I've scribbled over my WAN_DHCP addresses for privacy purposes.

    I've also got a Gateway Group:

    0_1529529092017_20180620 -- pfSense System Routing Gateway Groups.PNG


  • Rebel Alliance Global Moderator

    See that other thread on how dicked up the other guys setup was to why it wasn't working.. A clue to why yours isn't working is prob in there as well.


  • Rebel Alliance Global Moderator

    @beremonavabi said in NTP Not Working [SOLVED (mostly)]:

    RW_VPN is my VPN server

    Huh? Why would you vpn server your running on pfsense be setup as a gateway?

    Looks like he is shooting himself in the foot same way other guy was... Manual mode outbound nat and not natting what the ntp is trying to use as the source IP, etc.

    And for what reason are you using manual for your outbound nat?



  • Just thinking and typing out loud :

    Is this not just another case of trying to pass everything through the VPN tunnel ?

    Knowing that the ntp deamon probably starts before the VPN server, it will work for a while : the WAN connections works, (NAT) rules are fine.
    Then the VPN server starts, the gateways are shot in the back and reconstructed, so that all traffic goes out of the VPN, the new "WAN".
    Our ntp isn't informed, and is locked out.

    Something like that ?


  • Rebel Alliance Developer Netgate

    Firewall > NAT, Outbound tab. Add rule to top.

    • Disabled: Unchecked
    • Do not NAT: Unchecked
    • Interface: WAN (make one of these rules for each WAN)
    • Protocol: any
    • Source: This Firewall (self)
    • Destination: any
    • Not: Unchecked
    • Translation Address: Interface Address
    • Port or Range: Blank
    • Description: NAT anything out from the firewall itself


  • @jimp said in NTP Not Working [SOLVED (mostly)]:

    Firewall > NAT, Outbound tab. Add rule to top.

    Disabled: Unchecked
    Do not NAT: Unchecked
    Interface: WAN (make one of these rules for each WAN)
    Protocol: any
    Source: This Firewall (self)
    Destination: any
    Not: Unchecked
    Translation Address: Interface Address
    Port or Range: Blank
    Description: NAT anything out from the firewall itself

    Yay! Thanks, jimp. That got it. I had to reboot the pfSense box before it would work, though. I'd tried something similar a couple of weeks ago, but it was limited to UDP on port 123, was at the end of my list of outbound NAT rules, and, probably most importantly, I didn't reboot the box.


  • Rebel Alliance Developer Netgate

    You probably didn't need to reboot, just clear the states table (Diagnostics > States, Reset States tab)