Need to map source NTP (UDP port 123) traffic to another port
Tiscan last edited by
I have a rather interesting challenge I need assistance with. I am not currently running pfSense but have in the past and may well make the jump back if it allows me to work around this.
I have AT&T Uverse Gigapower service. One of the things they have decided to do is block traffic NTP (UDP port 123) that originates from their customers networks.
Now in some cases this doesn't break anything as some NTP clients don't initiate their queries with a source port of UDP 123, however many clients (like NTPD on Linux, Windows and OS X) do. It has been amazing how many things this has actually broken across my network.
This same issue breaks the ability for the router itself to sync time.
So on a local Linux machine what I tested was using iptables to change the source of the NTP traffic with a command like:
sudo iptables -t nat -A POSTROUTING -p udp -s X.X.X.X –sport 123 --dport 123 -j SNAT --to-source X.X.X.X:12345
And it works! With this in place NTPD (on this test machine) was able to sync time again.
So what I need to do is perform this same mapping at the network level. I need traffic with a source of UDP port 123 to be mapped to something else by the router so the AT&T network won't drop the packets. It doesn't matter what port it gets mapped to but I suppose a randomize port would be best.
So my question is this: Is it possible to have pfSense perform this mapping for the entire network? It would also need to perform this change locally so the router itself can sync time.
Any help would be greatly appreciated.
So I am confused.. So they don't block outbound traffic to dest 123, they only block outbound udp to 123 that is sourced from 123 as well?
Why do you need all your devices on your network to sync time to internet? Why would you not just have pfsense be your local network ntp server? That is really the whole point of pfsense running ntp ;)
Or run another ntp on your local network, and have it sync to outbound.. And have all your devices use that for ntp, etc.
Pretty sure pfsense uses the actual ntpd, and not openntpd - the openntpd version I believe source ports from random high ports like normal stuff. Off the top I do not believe its possible to change the official ntpd to not source from 123, but you could prob adjust that and then compile your own version.
You might be able to do some sort of nat on pfsense to have when it syncs to change the source port?? You really shouldn't have to worry about all your other devices since they really should be syncing to ntp on your local network anyway. If you have stubborn iot devices that do not allow you to set their ntp, or hand it too them via dhcp then you could always do a redirect of ntp traffic on pfsense to send them to either pfsense or some other ntp on your local network.
If you could not source nat or change the ntpd on pfsense to not source from pfsense, you could always just install the openntp and use that instead on pfsense or some other device on your network.
To be honest that is pretty nasty for isp to do.. WTF.. ISP how about you stay out of the business of what traffic I use on the public internet and provide me the connection ;) I could see if you where clearly spewing shittons of ntp traffic to shut that down on you.. But out of the box just blocking ntp - WTF???
for like $100 and a few minutes time you can turn a raspberry pi into a ntp server ;) Get a gps for it so you have PPS.. Use openntp on it so it doesn't use sourceport 123, or other option is chrony which pretty sure you can adjust or does not force 123 as source port.
Tiscan last edited by
Yep they are blocking outbound that is sourced on UDP 123. Probably to mitigate them being used as a surface for NTP reflection attacks? Regardless, poor decision IMO.
So I did a quick pfSense install to play around and guess what… everything seems to just work. I am assuming this is because of pfSense outbound NATing? Just a guess on my part though. pfSense itself wasn't able to sync time until I selected to have NTP only listen on the LAN, which then (again I am assuming) forces the sync through the outbound NAT whereas it doesn't when.
Point is it all works and pfSense yet again proves how amazing and flexible it is. ;)
You're correct about the IoT devices being a source of problem, but I also don't want to have to set time servers on everything and then have laptops not time sync when they are away from the home network. I could just redirect the NTP traffic to the pfSense box and I may also do that as it seems I will be migrating back to pfSense now.
So this appears to be solved. :)
Yeah.. Its quite possible that pfsense sync to outbound ntp goes through the outbound nat and therefore changes the sourceport. I can tell you that since I sync pfsense to my local ntp server, it does use 123 as the source port talking to ntp server on pfsense lan.
As to laptops.. While I guess could be a problem if they are away from home for extended periods.. Being gone for a few days and not able to sync to their home ntp shouldn't really be that all that big of an issue.
You could use a simple split dns trick ;) So setup say pool.ntp.org to resolve to your local ntp (pfsense) now clients are home they sync to your local and don't go outbound. If they are on the road they would resolve pool.ntp.org to some public ntp and use that..
This is what I do for my iot devices that like to just do what they want.. I have some tp-link hs110, and for some freaking reason they try and sync to uk.ntp.pool.org – stupid!! Your being handed ntp via dhcp - use it.. Freaking moronic coders ;) Not like your devices are only ever going to be in the uk.. If you want to use ntp pool, ok but don't code your devices to use a regional fqdn when clearly they are used outside that region...
I am not really a fan of redirecting of traffic via nat.. But hey your asking my dns for resolution I can resolve what your asking for to anything I want ;) hehehe