Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

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

1

0

Article ID: KB11436 KB Last Updated: 23 Nov 2019Version: 9.0
Summary:

When a firewall filter is configured on the loopback interface of a Juniper router that is 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:

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


user@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;
    }
}

user@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:

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

The NTP process is still up and running:

user@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
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.

user@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:

user@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:

user@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:

user@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

user@ulm>

The show ntp associations command might take a long time to produce the expected output. This is especially true in this example, because 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.

user@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 address on the loopback is configured as 127.0.0.1, it must be allowed in the firewall filter. If the loopback interface does not have an IP address, NTP will use the address of the interface that reaches the NTP server. Prior to Junos OS 8.0, the router used the numerically lowest address configured on the loopback interface instead

Note: For QFX5100 the filter term does not support "port". It supports "source-port".

Modification History:
2019/11/23: Added note on QFX5100 supporting "source-port".
2018/04/27:  Minor grammar corrections and added clarification about the loopback interface in the solution section.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search