Redirect NTP to pfSense not working for me

[billl]

You could also just select "Pass" for the associated filter rule and eliminate needing the associated rule altogether. I'm not sure what the shortcomings of that approach might be in this case, but you might want to have an actual rule around so that you can toggle logging in testing, or maybe to utilize advanced rule properties.

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

You might want to try changing !OPT2_IOWIFI address to !127.0.0.1.
Not saying what you have isn't right, but maybe trying something different will help to get you on the right track.
Also, what rule do you get when you click on the View the filter rule link?
I expect others will want to see that rule so that they can help further.

Thanks, I'll give that a try. Below is my filter rule. It is the first rule on the interface. I note that the Destination address on my rule is grey, your's is solid typeface. That may be the reason mine is grey.

My intention is to create a group for this situation but I wanted to make sure it worked for a single device before I proceed in order to simplify things.

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

You could also just select "Pass" for the associated filter rule and eliminate needing the associated rule altogether. I'm not sure what the shortcomings of that approach might be in this case, but you might want to have an actual rule around so that you can toggle logging in testing, or maybe to utilize advanced rule properties.

I don't think the suggestion here will work, if I understand your comment correctly. The associated rule is supposed to redirect incoming matching packets to loopback. By just creating a normal rule then you are filtering for loopback when the object is to redirect incoming IP tp loopback.

At any rate, I cannot do as you suggest in changing the Destination Address/mask field of the redirect entry form. The Address/Mask field is greyed out and does not accept an entry. In other words, if I attempt to duplicate your posted "edit redirect entry", where you have a Destination of the 127.0.0.1, I have a greyed out box.

According to the documentation I referenced in the top post the fields are also greyed out so it's odd that you were able to enter something in that field. And although I don't think it should matter, the interface I am working with is a wifi vlan behind pfSense. Seems like that should not be an issue.

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

You could also just select "Pass" for the associated filter rule and eliminate needing the associated rule altogether. I'm not sure what the shortcomings of that approach might be in this case, but you might want to have an actual rule around so that you can toggle logging in testing, or maybe to utilize advanced rule properties.

OK, I misread this suggestion. At the bottom of the NAT/Port Forward entry form is a box that defaults to 'associated filter rule' and I did not realize you were talking about that. I deleted my work and started over again. I still cannot enter the loopback addr in the greyed out box but I changed the last entry on the form to 'pass'. This particular entry is NOT in the documentation I referenced at the top.

I'm currently doing a packet capture and will see if there is any change.

thanks again

[JonH]

@JonH said in Redirect NTP to pfSense not working for me:

I changed the last entry on the form to 'pass'. This particular entry is NOT in the documentation I referenced at the top.
I'm currently doing a packet capture and will see if there is any change.

@Bill: Thanks,

I think this is solved now.
My problem may have been that I had only WAN selected (previously 'none' selected which was the wild card for all interfaces) and since packet tracing of individual interfaces worked I thought that is all I needed.

I now have selected 3 interfaces: WAN, the interface that this post is about, and localhost.
The packet trace does not show it redirected but the States table shows it is redirected.

I have a better understanding now and need to see if all the clients on this interface perform correctly.

[billl]

@JonH That's great news!

I gather you are referring to the Services / NTP / Settings / NTP Server Configuration / Interface setting?
FWIW, mine is just set to LAN (and all of my VLANs are configured from my LAN interface).
Can anyone advise on the implications of NTP server listening on WAN?

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

Can anyone advise on the implications of NTP server listening on WAN?

Yes, I'm referring to the NTP Server config that you reference.

As to listening on the WAN, I've seen a number of different opinions but my 2¢ is that NTP packets will only pass into the system when requested by pfSense unless there is otherwise a pass rule for NTP from internet. But I'm far from knowledgeable on this matter and still am uncertain that I have this right.

[billl]

@JonH
I was hoping that someone knowledgeable about this would provide advice for us on what the implications are of your NTP server listening on the WAN.
I would think (naively perhaps?) that I'd only want an NTP server listening on WAN if I wanted it to provide NTP services to external networks.

As far as "a pass rule for NTP from internet", I don't think you need one (unless you are intending to provide the internet with NTP services). I expect NTP reply packets are allowed back in to the NTP server because they are associated with the state of their request.

Unless you are indeed intending to provide external NTP services, you might want to test removing WAN from the interfaces that NTP is listening to, and see if you still get all of the functionality that you require.
good luck!

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

@JonH
I would think (naively perhaps?) that I'd only want an NTP server listening on WAN if I wanted it to provide NTP services to external networks.

If you are not running NTP on WAN how are you going to keep pfSense time sync'd? Maybe I'm missing something here. I don't know if using a different interface would keep pfSense sync'd.

As far as "a pass rule for NTP from internet", I don't think you need one (unless you are intending to provide the internet with NTP services). I expect NTP reply packets are allowed back in to the NTP server because they are associated with the state of their request.

Correct, this is what I meant. Thus, only reply packets from the NTP servers specified in General Setup and/or NTP service page are accepted, all other is dropped.

Unless you are indeed intending to provide external NTP services, you might want to test removing WAN from the interfaces that NTP is listening to, and see if you still get all of the functionality that you require.

I guess that is worth some time to discover. All the stuff I've read so far has WAN selected or else the specifics are skipped over. I've seen nothing saying 'don't do this because it's a security hole'.

[billl]

@JonH said in Redirect NTP to pfSense not working for me:

If you are not running NTP on WAN how are you going to keep pfSense time sync'd?

Sorry to dive into semantics; I believe the interfaces selected in Services / NTP / Settings / NTP Server Configuration / Interface are those that it "listens" on, not so much "runs" on.
When an internal device on my system wants to know the time, it sends out the request on port 123 and it doesn't matter what IP address it thinks it should use for an NTP server. If that IP address is not 127.0.0.1, then the request gets port-forwarded to 127.0.0.1. I have NTP server listening on LAN (only) (port 123), so it gets the request and it replies to the client device.

The question I think we are asking, "how is the NTP server itself allowed to request time from its own configured servers?".
I have always expected this "behind the scenes" ability is similar to how pfSense is able to upgrade itself and its packages without specific rules allowing it out to the internet; I expect NTP server (ntpd) has special privileges allowing it go out to its configured time servers. Furthermore, any replies from its configured times servers are allowed back in because they share state with the requests.
In the following image, reach values of 377 are telling me that my NTP server is having no trouble reaching its configured time servers. I only have NTP server listening on LAN, no rules allowing LAN out (those only exist for VLANs), and no rules/port forwards allowing anything in through my one and only WAN. Also, for the record, in case this matters, I have outbound NAT simply using automatic rules and am not running CARP.

@JonH said in Redirect NTP to pfSense not working for me:

I've seen nothing saying 'don't do this because it's a security hole'.

I didn't mean to suggest that it is a security hole to have NTP listen on WAN, I was just wondering what the implications of it are. For it to be a security hole I'd think you would need to grant access (via port forward & rule allowing in port 123), and not so much a 'hole' if you restricted src and/or limited rate.

I would hereby like to invite any and all NTP experts to provide definitive feedback!
thanks :)
Bill

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

I would hereby like to invite any and all NTP experts to provide definitive feedback!

I found some interesting, although maybe not definitive, info here:
ntp not working

[Gertjan]

@billl said in Redirect NTP to pfSense not working for me:

I have always expected this "behind the scenes" ability is similar to how pfSense is able to upgrade itself and its packages without specific rules allowing it out to the internet; I expect NTP server (ntpd) has special privileges allowing it go out to its configured time servers.

Every Interface can have firewall rules.
These rules controls what can go 'into' pfSense. They are filtering the inbound (from a pfSense perspective) traffic.

That's why pfSense - a router/firewall, works just fine with no rules on the WAN interface and a (one) generic pass rule on the LAN interface.

Also : keep in mind that a (any) process that execute on pfSense can pick any interface and go where ever it want to go.
An automatic update checker contacts the pfSense update server ones to check if there are new package updates.
A NTP process checks ones in a while one of it's time supplier to sync the time.
The acme package upgrades every 60 days a certificate.
A DyNDNS is updated when the WAN IP changed.
Etc.
All this traffic coming from pfSense itself doesn't need any firewall rules on any interface.

Interface firewall rules can not block them : the traffic initiates from the inside ****

**** Floating rules could control traffic from the "pfSense inside".

Edit : typically, the selected Interface for,the NTP service are :
Localhost = 127.0.0.1 so pfSense itself can ask the time.
All "LAN type interfaces" like LAN, OPT, etc so internal networks can ask for the time. A firewall rule on these interfaces should permit the UDP port 123 access.

WAN type interfaces are not selected, because typically you do not want to be a NTP time source for hosts on the Internet. Even if WAN is selected you still need a firewall rule (UPP port 123) on the WAN type interfaces so these foreign hosts can question your NTP.

The Interfaces select list is the list with interfaces on which the NTP service listens, as a server, for client time requests.

Open the console, option 8:

netstat | grep 'ntp'

so you can check on which ports and IP addresses NTP is 'bound'. (listens).

[billl]

@JonH said in Redirect NTP to pfSense not working for me:

I found some interesting, although maybe not definitive, info here:
ntp not working

Thanks @JonH, that is an interesting thread.

In support of my positions,
@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.
..
I do not have wan selected, and ntp works just fine to outside ntp servers.
@Gertjan said in NTP Not Working [SOLVED]:
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.

In that thread, the OP had a lot going on with VPNs, Gateways and Automatic Outbound NAT; at least a lot more than I do. It appears to me that when he added WAN as a listening interface for NTP it might have been somehow affecting/improving the situation for outbound NAT, since the addition of @jimp's Outbound NAT looks like it eliminated the need for WAN to be a listening interface.

So, that thread answers my question by providing at least one implication of NTP server listening on WAN!
thanks :)

[billl]

@Gertjan Thank you! that's a nice summary :)

[JonH]

@billl said in Redirect NTP to pfSense not working for me:

In support of my positions,
@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.

Yes, I now agree. But as @Gertjan said if WAN is selected you need to open port 123 and so since I didn't have it open I had no concern about Internet connection to my ntpd. Now that I have this much better undertanding there is no purpose for me to have the WAN interface selected.

I have changed it and removed the WAN interface from my ntpd setting. And after running the netstat command that @Gertjan posted I see that I was hung up by mentally mixing up the WAN interface and my LAN gateway address. I got tunnel vision and could not see how the rest of my system (4 subnets) could maintain time sync with my pfSense box if it didn't sync with pfSense.

That netstat command raised the curtain for me. But I will keep my eye on my time in various devices for awhile. As they say, Trust but Verify.

Thanks for the dialog, it really helped.

[stephenw10]

Yes, the ntpd daemon is not the same as the ntp client.

Yes, the server listens on all interfaces by default but that's not a problem unless you are allowing ntp traffic into WAN with a firewall rule.

Steve