Skip to main content
SYN_bit
SYN_bit
New Member
January 11, 2018
Solved

NTP responses blocked, even though allowed through policy

  • January 11, 2018
  • 1 reply
  • 27567 views

Hi All,

 

I'm trying to get NTP working through my FortiWifi 60D. However, normal NTP traffic gets blocked because it is using a privileged port as source port:

 

<linux-host-behind-fortigate># ntpdate nl.pool.ntp.org 11 Jan 11:46:19 ntpdate[14461]: no server suitable for synchronization found <linux-host-behind-fortigate>#

 

This results in these packets (captured on the linux host):

11:46:16.440887 IP 10.0.0.108.123 > 217.77.132.1.123: NTPv4, Client, length 48 11:46:16.640870 IP 10.0.0.108.123 > 91.148.192.49.123: NTPv4, Client, length 48 11:46:16.840873 IP 10.0.0.108.123 > 129.250.35.250.123: NTPv4, Client, length 48 11:46:17.040829 IP 10.0.0.108.123 > 131.211.8.244.123: NTPv4, Client, length 48

 

When I force ntpdate to use a non-privileged port, all is well:

 

<linux-host-behind-fortigate># ntpdate -u nl.pool.ntp.org 11 Jan 11:46:35 ntpdate[14462]: adjust time server 131.211.8.244 offset 0.001271 sec <linux-host-behind-fortigate>#

This results in these packets (captured on the linux host):

11:46:28.746542 IP 10.0.0.108.51394 > 217.77.132.1.123: NTPv4, Client, length 48

11:46:28.857244 IP 217.77.132.1.123 > 10.0.0.108.51394: NTPv4, Server, length 48 11:46:28.946480 IP 10.0.0.108.51394 > 91.148.192.49.123: NTPv4, Client, length 48 11:46:29.054651 IP 91.148.192.49.123 > 10.0.0.108.51394: NTPv4, Server, length 48 11:46:29.146484 IP 10.0.0.108.51394 > 129.250.35.250.123: NTPv4, Client, length 48 11:46:29.255057 IP 129.250.35.250.123 > 10.0.0.108.51394: NTPv4, Server, length 48 11:46:29.346372 IP 10.0.0.108.51394 > 131.211.8.244.123: NTPv4, Client, length 48 11:46:29.455309 IP 131.211.8.244.123 > 10.0.0.108.51394: NTPv4, Server, length 48 However, most ntp daemons use the privileged port as source port and I don't want to reconfigure all systems behind the FortiWifi.

 

Is there a configuration setting that makes the firewall accept source ports in the privileged range?

I already tried creating a custom service with source and destination ports equal to 123, but that did not help. Cheers, Sake

Best answer by SYN_bit

oheigl wrote:

Try to analyze the traffic on the FortiGate, maybe some other device is blocking requests. 

diag sniffer packet any 'port 123' 4 0 a

 

I see that the fortigate translates the port to another privileged port:

 

2018-01-11 15:05:59.279387 SYN-bit_OFFICE in 10.0.0.8.123 -> 95.211.160.148.123: udp 48 2018-01-11 15:05:59.279537 INTERNET out <my-public-IP>.634 -> 95.211.160.148.123: udp 48 2018-01-11 15:05:59.279569 wan1 out <my-public-IP>.634 -> 95.211.160.148.123: udp 48

As my ISP modem is in bridged mode, there is nothing in my own network after the fortigate. Combined with this text from the ntpdate manpage, I suspected the Fortigate:

 

     -u      Direct ntpdate to use an unprivileged port for outgoing packets.              This is most useful when behind a firewall that blocks incoming              traffic to privileged ports, and you want to synchronise with              hosts beyond the firewall.  Note that the -d option always uses              unprivileged ports.

However, I just captured traffic in between my modem and my fortigate, and it seems something upstream is blocking the NTP requests or the responses, as I do not see any traffic coming back (which is whay the fortigate was also telling me).

 

I changed the NAT for this particular rule to "fixed port" to keep 123 as source port and now it works:

 

2018-01-11 15:21:51.509456 SYN-bit_OFFICE in 10.0.0.8.123 -> 95.211.160.148.123: udp 48 2018-01-11 15:21:51.509540 INTERNET out <my-public-IP>.123 -> 95.211.160.148.123: udp 48 2018-01-11 15:21:51.509567 wan1 out <my-public-IP>.123 -> 95.211.160.148.123: udp 48 2018-01-11 15:21:51.516922 wan1 in 95.211.160.148.123 -> <my-public-IP>.123: udp 48 2018-01-11 15:21:51.516922 INTERNET in 95.211.160.148.123 -> <my-public-IP>.123: udp 48 2018-01-11 15:21:51.517003 SYN-bit_OFFICE out 95.211.160.148.123 -> 10.0.0.8.123: udp 48

 

 

Thank you for making me look a little deeper into the issue (which I should have done in the first place).

 

Weird though that my ISP seems to block NTP traffic if it is from a privileged port other that 123.

 

THX! Case closed :)

1 reply

oheigl
oheigl
New Member
January 11, 2018

The default NTP service doesn't limit the source port value, you can look it up under Policy & Objects > Services

 

Try to analyze the traffic on the FortiGate, maybe some other device is blocking requests. 

 

diag sniffer packet any 'port 123' 4 0 a

 

If you can see that it's the FortiGate, check your policies and objects, or start a debug flow :)

emnoc
emnoc
New Member
January 11, 2018

You need to use  diag debug flow filter port 123 and validate it's really blocked. std port is 123 udp.

 

 

e.g

 

diag debug reset

diag debug en

 diag debug flow filter port 123

diag debug flow show console  enable

diag debug flow trace start 40

 

 

re-run the ntpdate or query command

 

 

Ken

 

Terms & ConditionsAccessibility statement