Protect-RE (loopback) Firewall Filter does not discard OSPF packets from non-permitted prefixes

Product Affected:This issue affects any EX4300, EX4600, QFX3500, QFX5100 platforms running Junos OS.

Problem:On EX4300, EX4600, QFX3500, QFX5100 platforms, a firewall filter applied on the lo0 interface may not work as expected.  OSPF adjacencies form irrespective of the source-address.

The adjacency should never form using the configuration below.
It should only form if the correct source-address is used in the OSPF_NEIGHBORS term, in this case, the 192.168.1.x/24 subnet.This same configuration works on the EX4200 as expected.

The adjacency does not form until the incorrect source-address is replaced with the correct one.In below example, an incorrect source-address 172.16.1.x/32 subnet is used intentionally in the OSPF_NEIGHBOR term.

The term should not match and it should go to the next term – DENY_ANY term, where the action is count and discard. However, the adjacency forms regardless of the source-address in the OSPF_NEIGHBOR term.
It is not discarded or counted by DENY_ANY term as indicated by the formation of a Full adjacency and DENIED_TRAFFFIC counter.JTAC Lab setup DetailsThis limitation is reproduced in the JTAC lab using EX4300. EX4300-1 – ge-0/0/15 ———— ge-0/0/15 – EX4300-2Configuration
{master:0} root@ospf-1> show configuration | display set set version 13.2X51-D37.1 set system host-name ospf-1set system root-authentication encrypted-password “$1$QKgKM4mj$SjcxtW9i/ILQQYLK2IMzF1″set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24set interfaces lo0 unit 0 family inet filter input OSPF_FILTERset interfaces lo0 unit 0 family inet address 1.1.1.1/32set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.2/32set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospfset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then logset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then acceptset firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFICset firewall family inet filter OSPF_FILTER term DENY_ANY then discard{master:0}root@ospf-2> show configuration | display setset version 14.1X53-D30.3set system host-name ospf-2set system root-authentication encrypted-password “$1$m0KUv05.$jkU1qDmiRaEuW5zTQxNm80″set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24set interfaces lo0 unit 0 family inet filter input OSPF_FILTERset interfaces lo0 unit 0 family inet address 2.2.2.2/32set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.1/32set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospfset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then logset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then acceptset firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFICset firewall family inet filter OSPF_FILTER term DENY_ANY then discard

Solution:Root CauseIn a nutshell, EX4200 and EX4300 use different chipsets and hence there are changes in the way these (multicast destination IP – 224.0.0.X) packets are handled. OSPF packets are making it to CPU due to implicit rule to allow IP reserved Multicast packets which is placed before last discard term.

This is needed to allow all multicast transit packets to not get discarded. We are basically running into chipset limitations.

To handle limitations/behaviors, our design expects user to add explicit discard term for the kind of packets that are not needed to be trapped to CPU.

The last discard term discards regular L3 data packets (except destination IP=224.0.0.x packets) and control packets which are L3 routed and not explicitly accepted by terms before.We are basically dealing with below limitations:Chipset on EX4300, EX4600, QFX3500, QFX5100 platforms sets destination port as CPU port even for transit multicast packetsEX4300, EX4600, QFX3500, QFX5100 platforms chipset’s action resolution engine, Discard wins over any action and hence in the absence of implicit term to allow reserved multicast packets, protocol packets would get discarded if user does not configure explicit term for each and every packet which is not scalable.EX4300, EX4600, QFX3500, QFX5100 platforms chipset does not treat TTL expired packets as routed packets and loopback filter being applied on family inet, it is expected to act only on L3 routed packetsSolutionTo overcome this limitation, it is required to configure explicit discard term for unwanted OSPF packets as below to overcome specific chipset limitations.
root@ospf-2# show | compare
[edit firewall family inet filter OSPF_FILTER]
term OSPF_NEIGHBOR { … }
+ term OSPF_tmp {
+ from {
+ source-address {
+ 192.168.1.1/32;
+ }
+ protocol ospf;
+ }
+ then {
+ count intersted_SA;
+ discard; <———
+ }
+ }
term DENY_ANY { … }

root@ospf-2> show ospf neighbor
(no output returned)This is specific to the packets with multicast destination IP – 224.0.0.X address.
Since OSPF hello uses 224.0.0.5 address, it requires explicit discard for unwanted source IP addresses.

Any other terms which do not use this address should not be impacted.

For example, SSH and IPV6 traffic is not affected by this limitation.

Workaround:See Solution section above.

Implementation:Modification History: 2016-04-26: Initial publication2016-05-02: Removed software version reference.  Affects all versions of Junos OS.

Related Links: CVSS Score:5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)

Risk Level:Medium

Acknowledgements: