NTP responses blocked, even though allowed through policy

[SYN_bit]

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

[oheigl]

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]

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

[SYN_bit · Accepted solution]

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 :)

[oheigl]

Such a problem is new to me, never had to use fixed port before for NTP sync. Are you located in USA, maybe you need to pay extra for NTP access 

Glad it works now, you could also use the NTP server feature of the FortiGate, so only the firewall is syncing the time with the external NTP, and all other devices only generate internal traffic. That's how I usually configure it (if no domain controller or something else is available)

[Christian_v_R_]

You use FortiOS 5.6.x? This is an new Bug or new Future and not an USA specific problem ;)

Diag Flow with FortiOS 5.4.8:

id=20085 trace_id=11 func=__ip_session_run_tuple line=3209 msg="SNAT 10.82.16.134->5.147.253.12:123"

Diag Flow with FortiOS 5.6.3

id=20085 trace_id=1 func=__ip_session_run_tuple line=3209 msg="SNAT 10.82.16.134->5.147.253.12:634"

[bvanhaastrecht]

SYN_bit wrote:

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

Saw your posts on the Ziggo forums. I had the exact same problems. Setting the NTP policy in the fortigate to fixedport solved the problem. Ziggo apparently does not allow requests from other sourceports anymore.