NTP Redirection Fails
-
I've been trying to get NAT redirection to forward outgoing NTP requests to NTP server on my pfSense box. I've read the (old) threads and the old article related to this, yet I still can't get it to work.
I've attached screenshots of what I believe to be the relevant NAT and firewall settings. Any help you can provide would be greatly appreciated.
(Note: I've tried variations on what is shown in the screenshots. For example, rather than forwarding NTP to 127.0.0.1 I've also tried forwarding it to 192.168.1.1, the LAN interface of the pfsense box.)
-
why do you want/need to do this? Why would your lan clients not just point to your pfsense or whatever ntp server your pointing to directly?
I never understand trying to intercept some clients traffic and point it to you want, when they should be pointing to you anyway. Just block what you don't want them to do.. If you don't want them to talk to ntp outside your network.. Then block it and tell them to point to your local ntp servers..
If they try to talk to say 0.us.pool.ntp.org guess it wont work ;) And they can point to what they should be pointing too..
-
I have several NTP clients on my network that aren't configurable (e.g., some media extenders, my media software, Sonos components, etc.). And even if they were, its a lot easier to redirect them to my NTP server than figure out how to edit them all. I know they're pointing to other NTP servers since I see snort and pfblocker-ng blocking some of their traffic since they're going to NTP servers at IPs that are on blacklists.
I'll admit that's more of a minor annoyance than a serious problem. Still, it's been troubling to me that I can't get this to work, given that I seem to be doing it correctly. The same went for NAT reflection, which I'll readily admit split DNS works better for anyway.
For significantly, I'm running into a problem with a different pfsense package that happens to use NAT redirection. It looks like it might be a NAT problem. Now I'll obviously continue to resolve that specific problem, but getting NAT redirection working in a simpler case- and it doesn't get much simpler than just redirecting UDP port 123 traffic- would help with the troubleshooting. Plus, it would help with this other minor problem I've having with NTP clients.
Do you see anything obviously wrong with my NAT configuration? Are there other settings that I should be looking at?
-
You must put it ABOVE the generic "default allow LAN to any" IPv4 rule.
-
You must put it ABOVE the generic "default allow LAN to any" IPv4 rule.
Thanks. To be clear, you're talking about moving the LAN firewall rule up. Out of curiosity, does that really change anything? I mean, the default allow should pass the traffic through even if the NTP-specific rule weren't there, right?
I did move this up, and then enabled logging. That provided some helpful diagnostic info. When I look at the firewall logs, I see only traffic originating from source port 123 actually seems to be redirected to localhost. At least, I tried a handful of NTP clients and usually things don't seem to be getting forwarded- I don't see the traffic in the log, nor do attempts to sync time with a random IP work. However, after a while I started seeing traffic coming out of my non-configurable devices. The common theme was that they were all destination and source port 123.
Is my NAT rule wrong? Shouldn't it be redirecting all traffic to UDP port 123, regardless of the source port?
-
I cannot see where are you setting source port in the first place. No such thing anywhere on your screenshots.
-
I cannot see where are you setting source port in the first place. No such thing anywhere on your screenshots.
Doesn't the first screenshot- portforwarding.png- show the relevant NAT redirection settings? I don't set a source port there, but it sure looks like the pfsense box is only redirecting source port 123.
-
I cannot see where are you setting source port in the first place. No such thing anywhere on your screenshots.
Doesn't the first screenshot- portforwarding.png- show the relevant NAT redirection settings?
Yes, it does. There is no such thing like source port set. Also not sure what logs are you looking at. There is no logging set for that rule.
-
Yes, it does. There is no such thing like source port set. Also not sure what logs are you looking at. There is no logging set for that rule.
I just want to make sure we're on the same page. My understanding is that its possible to set up NAT redirection rules that would only catch packets with a certain source port(s). So it exists. But in my configuration I didn't set it, so it should be grabbing things with any source port. Right?
As for logs, I was looking at the firewall logs tried to the LAN rule you had me move up before the IPv4 default allow. Here's an example of a line I see:
May 6 10:44:44 LAN NAT NTP redirection test (1430921238) 192.168.1.183:123 127.0.0.1:123 UDPAfter watching more traffic, I'm starting to see a couple examples of other log entries that don't come from source port 123. But oddly I still don't see any traffic from my windows machines when I try to use Windows built-in NTP client or the AnalogX client. I may need to do some packet captures to see what's going on.
-
Ok this is like drop dead simple.. So my pfsense 192.168.1.253 lan IP, syncs time with 192.168.1.40 my ntp server on my network.
So from below example I do a query to pool.ntp.org and you can see what its using for source. Then I put in the port forward and do the same exact query and you see that even though I query pool.ntp.org the source is my ntp server, so clearly it queried pfsense.
-
For example, rather than forwarding NTP to 127.0.0.1 I've also tried forwarding it to 192.168.1.1, the LAN interface of the pfsense box.
What do you have selected for your NTP interfaces under Services - NTP?
BTW, you can get rid of firewall WAN rules 2, 3 & 4. The hidden Default Deny rule blocks anything not explicitly allowed, so manually adding those blocks is redundant.
-
Ok this is like drop dead simple.. So my pfsense 192.168.1.253 lan IP, syncs time with 192.168.1.40 my ntp server on my network.
So from below example I do a query to pool.ntp.org and you can see what its using for source. Then I put in the port forward and do the same exact query and you see that even though I query pool.ntp.org the source is my ntp server, so clearly it queried pfsense.
Thanks. This is what I needed to know. I had been using AnalogX TimeSync for some of my testing, which claimed to be using NTP. Instead its using the TIME protocol on port 37, which obviously wasn't being forwarded. That's part of the reason things weren't working as expected.
I'm not entirely convinced things are either getting forwarded correctly, or that my NTP server is responding correctly, so these steps will help greatly with my testing.
-
@KOM:
For example, rather than forwarding NTP to 127.0.0.1 I've also tried forwarding it to 192.168.1.1, the LAN interface of the pfsense box.
What do you have selected for your NTP interfaces under Services - NTP?
Nothing is selected, which I think means NTP should be listening on everything, including localhost (and WAN and LAN, for that matter). I've been a little confused about what I'm supposed to do there. Should I forward to my pfsense box LAN IP (192.168.1.1) or local host? Does it matter?
@KOM:
BTW, you can get rid of firewall WAN rules 2, 3 & 4. The hidden Default Deny rule blocks anything not explicitly allowed, so manually adding those blocks is redundant.
Thanks. I know they're not doing anything. Well, actually they are. Just out of curiosity, I want to log external accesses to ports 80, 3389 and 3390, even though the firewall isn't going to let them through. So, default deny isn't logged, but those rules are. For a while I was trying to log default deny, but that was far too much to log. The MOCA rule was there in an attempt to NOT log those, but I discovered there's a hidden firewall rule that's handled before the user-defined rules that grabbed (and logged) that traffic. I just never cleared the MOCA rule out.
-
Does it matter?
Not any more since you found the source of your error. I don't know for sure if it properly responds to all interfaces via the loopback address. The help text specifically mentions it will bind to all interfaces if none are selected, but does that include loopback when it's not in the list? Who knows. I've seen funny things before like command-line squidclient not working if you specify loopback but working if you specify LAN IP. That's why I was checking and perhaps getting you to select the interface that matters and see if there is any change.
-
Ok this is like drop dead simple.. So my pfsense 192.168.1.253 lan IP, syncs time with 192.168.1.40 my ntp server on my network.
So from below example I do a query to pool.ntp.org and you can see what its using for source. Then I put in the port forward and do the same exact query and you see that even though I query pool.ntp.org the source is my ntp server, so clearly it queried pfsense.
Again, this was great. I didn't know how to use w32tm.
Quick question- how do you get your NTP server to use itself as the reference ID? In my case it reports 129.6.15.30, which is the IP address of the NTP server my pfsense box syncs with. But, I'm pretty sure my box is responding, not the NIST one. Are you using GPS time?
-
Its not using itself as a reference - I have a ntp server running on 192.168.1.40.. If I query it its using stratum 1 servers.. All my boxes and devices use it as ref, that first one is my pc I am on, then I changed over and looked at the server, then last one is pfsense showing what its talking too.
As you can see pfsense uses 192.168.1.40 as its ref, not itself. Pfsense is a vm - using it as a time source would be pretty inaccurate.
As to w32tm yes it is a ok tool for that sort of thing.. As to what you were using to sync - that analog X or whatever, why?? Why not just run ntp? Runs on pretty much anything, as you can see its running on windows.. While w32tm is not a bad cmd line tool for troubleshooting, the time sync in windows is a bit lacking. I always just turn it off and install ntp directly. You can get latest builds from here http://www.satsignal.eu/ntp/setup.html
-
Its not using itself as a reference - I have a ntp server running on 192.168.1.40.. If I query it its using stratum 1 servers.. All my boxes and devices use it as ref, that first one is my pc I am on, then I changed over and looked at the server, then last one is pfsense showing what its talking too.
As you can see pfsense uses 192.168.1.40 as its ref, not itself. Pfsense is a vm - using it as a time source would be pretty inaccurate.
Got it. Thanks.
As to w32tm yes it is a ok tool for that sort of thing.. As to what you were using to sync - that analog X or whatever, why?? Why not just run ntp? Runs on pretty much anything, as you can see its running on windows.. While w32tm is not a bad cmd line tool for troubleshooting, the time sync in windows is a bit lacking. I always just turn it off and install ntp directly. You can get latest builds from here http://www.satsignal.eu/ntp/setup.html
I was just using AnalogX for testing. I wanted a free, simple NTP client that I knew how to use.
I wasn't using w32tm at the command line because I didn't know how to. I tried playing with settings in the time/date menu, but I found that it wasn't particularly reliable. Outside of testing, I've found that the Windows utility both fails often, and isn't easily configurable to sync more than one per week (playing with the registry doesn't seem to fix it permanently- I just had it reset back to once per week by itself.) On two machines in particular I have several reasons for wanting to keep the clocks within a couple seconds of the real time, I've generally found I (usually) lose more than that over a week. So, thanks for the link to the ntp utility. I'll give it a try.