Knowledge Search


×
 

Why does the Network Time Protocol (NTP) stop working if a loopback firewall filter is applied?

  [KB11436] Show Article Properties


Summary:

When a firewall filter is configured on the loopback interface of a Juniper router running Junos, the show ntp status and show ntp association commands may not produce the expected output, even though the NTP daemon is running and the address of the configured NTP server is allowed by the loopback filter.

Symptoms:

When the NTP show commands are used, the Command Line Interface (CLI) prints localhost: timed out, nothing received. This occurs when a firewall filter is applied on the loopback interface. As soon as the firewall filter is de-activated, this behavior is no longer observed.

Consider the following configuration:

talal@ulm# show system ntp
server 172.17.27.46;
source-address 10.0.20.100;


talal@ulm# show interfaces lo0
unit 0 {
    family inet {
        filter {
            input Loopback-Firewall-Filter;
        }
        address 127.0.0.1/32;
        address 10.0.10.100/32;
        address 10.0.20.100/32 {
            primary;
        }
        address 10.0.30.100/32;
    }
}

talal@ulm# show firewall family inet filter Loopback-Firewall-Filter
term Allow-SSH {
    from {
        protocol tcp;
        port ssh;
    }
    then accept;
}
term Allow-NTP {
from {
source-address {
172.17.27.46/32;
}
protocol udp;
port ntp;
}
then accept;
} term Deny-Anything-Else { then { reject; } }

When this configuration is committed, the NTP show commands produce the following output:

talal@ulm> show ntp status
localhost: timed out, nothing received
***Request timed out
talal@ulm> show ntp associations localhost: timed out, nothing received
***Request timed out

The NTP process is still up and running:

talal@ulm> start shell % ps aux | grep ntp root 4283 0.0 0.0 1336 688 ?? S Mon03PM 0:00.19 /usr/sbin/tnp.sntpd -N
root 4301 0.0 0.1 1976 2000 ?? S Mon03PM 0:10.85 /usr/sbin/xntpd -j -N -g (ntpd)
remote 25485 0.0 0.0 408 288 p1 R+ 3:46PM 0:00.00 grep ntp
Cause:

Solution:

To execute the NTP show commands, the router will query itself by sending traffic on the loopback interface. If this traffic is not allowed by the loopback filter, the show commands fail. To resolve this issue, the filter configuration must be modified.

Monitoring of the traffic shows that a local NTP request is sent via the lo0 interface. The reply, which is also local, is rejected by the input firewall filter on lo0. This happens each time an NTP show command is entered. The source and destination addresses of the NTP request are both equal to the source-address (10.0.20.100), which is specified in the NTP configuration.

talal@ulm> monitor traffic interface lo0 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on lo0, capture size 96 bytes

16:19:06.206759  In IP 10.0.20.100.54729 > 10.0.20.100.123: NTPv2, Reserved, length 12
16:19:06.206825  In IP 10.0.20.100 > 10.0.20.100: ICMP host 10.0.20.100 unreachable - admin prohibited filter, length 36
16:19:11.207405  In IP 10.0.20.100.54729 > 10.0.20.100.123: NTPv2, Reserved, length 12
16:19:11.207448  In IP 10.0.20.100 > 10.0.20.100: ICMP host 10.0.20.100 unreachable - admin prohibited filter, length 36

When the firewall-filter is changed to explicitly allow the NTP source-address, this behavior is no longer observed:

talal@ulm# show firewall family inet filter Loopback-Firewall-Filter
term Allow-SSH {
    from {
        protocol tcp;
        port ssh;
    }
    then accept;
}
term Allow-NTP {
    from {
        source-address {
            172.17.27.46/32;
            10.0.20.100/32;
        }
        protocol udp;
        port ntp;
    }
    then accept;
}
term Deny-Anything-Else {
    then {
        reject;
    }
}

In this case, monitoring of the traffic shows that with each NTP show command being entered, NTP traffic is being sent (and received) via the lo0 interface:

talal@ulm> monitor traffic interface lo0 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on lo0, capture size 96 bytes

16:24:35.953912  In IP 10.0.20.100.56892 > 10.0.20.100.123: NTPv2, Reserved, length 12
16:24:35.954212  In IP 10.0.20.100.123 > 10.0.20.100.56892: NTPv2, Reserved, length 348

The show ntp status command produces the expected output:

talal@ulm> show ntp status
status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Thu Feb 14 03:06:23 UTC 2008 (1)",
processor="i386", system="JUNOS9.0R1.10", leap=00, stratum=2,
precision=-20, rootdelay=170.961, rootdispersion=21.583, peer=46724,
refid=172.17.27.46,
reftime=cbc2b0d7.b5d026c0  Wed, Apr 30 2008 10:48:23.710, poll=6,
clock=cbc2b0ef.b402b32b  Wed, Apr 30 2008 10:48:47.703, state=4,
offset=18.736, frequency=58.615, jitter=1.425, stability=0.080

talal@ulm>

The show ntp associations command might take a long time to produce the expected output. This is especially true in this example, as DNS traffic is not allowed by the firewall filter. This is a separate issue, the discussion of which is outside the scope of this article.

talal@ulm# run show ntp associations no-resolve
***Can't find host localhost
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*172.17.27.46    .GPS.            1 u   47   64   17  170.125    0.934   1.228

If no source-address is configured for NTP and the router is running Junos OS 8.0 or later, the primary address of the loopback interface is used by the router to query itself. This is the address that should be allowed in by the firewall filter. If the IP on the loopback is configured as 127.0.0.1, it must be allowed in the firewall filter. Prior to Junos OS 8.0, the router used the numerically lowest address configured on the the loopback interface instead.

Related Links: