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

[MX/SRX] The behavior of firewall filters that are applied on the loopback interfaces in virtual routers

0

0

Article ID: KB21326 KB Last Updated: 18 Mar 2014Version: 3.0
Summary:
This article provides information about the behavior of the firewall filters that are applied on loopback interfaces, which are part of virtual routers.
Symptoms:
To protect the control-plane (routing engine) from various attacks that enter an interface, which is part of a virtual router.
Cause:

Solution:
To protect the routing engine or control plane from various DoS attacks via self traffic, such as SSH, Telnet, HTTP, HTTPS, and so on, a firewall filter has to be applied on the loopback interface (lo0 unit 0 (lo0.0)), which is part of the inet.0 default routing instance.

In the default routing instance, not more than one logical unit for the loopback interface (lo0) can be present. If more than one logical unit is configured in inet.0,  the following commit error is generated:
root@srx100-4# commit check

[edit interfaces lo0]

'unit 1'

if_instance: Multiple loopback interfaces not permitted in master routing instance

error: configuration check-out failed

  A logical unit of the loopback interface can be associated with the custom routing-instance. To illustrate the behavior of firewall filters with multiple loopback units, consider the following setup:

SRX-1 is acting as the traffic (SSH) initiator and SRX-2 is the device that is under testing to protect the routing-engine of SRX2, which has two routing-instances; one default instance and one custom routing-instance (of type virtual-router) known as test. In SRX-2, the fe-0/0/0.0 and lo0.0 interfaces are part of inet.0 and the fe-0/0/1.0 and lo0.1 interfaces are part of the test routing-instance.


SRX-2 (device being tested):
  • fe-0/0/0.0, IP 10.20.30.1/30---------IP 10.20.30.2/30 , fe-0/0/0.0   SRX-1(Traffic Initiator)
  • fe-0/0/1.0, IP 10.20.40.1/30---------IP 10.20.40.2/30 , fe-0/0/1.0
On SRX-2, fe-0/0/0.0 and lo0.0 are part of inet.0. fe-0/0/1.0 and lo0.1 are part of test.inet.0 On SRX-1, both fe-0/0/0.0 and fe-0/0/1.0 are in the inet.0 default instance.
Scenario 1:

If Filter A is configured on the default loopback interface and Filter B on the routing-instance loopback interface, the routing instance uses Filter B:
root@srx-2# show firewall 
filter A {
    term 1 {
        then {
            count A-rejected;
            reject;
        }
    }
}
filter B {
    term 1 {
        then {
            count B-accepted;
            accept;
        }
    }
}

[edit]
root@srx-2# show interfaces lo0 
unit 0 {
    family inet {
        filter {
            input A;
        }
    }
}
unit 1 {
    family inet {
        filter {
            input B;
        }
    }
}

Verification:
root@srx-1# run ssh 10.20.30.1

ssh: connect to host 10.20.30.2 port 22: Connection refused >>> rejected because of filter A applied in inet.0

[edit]

root@srx-1# run ssh 10.20.40.1

root@10.20.40.2's password: >>> accepted because of filter B applied in test.inet.0 routing instance
Scenario 2:

If Filter A is configured on the default loopback interface, but a filter is not configured on the routing-instance loopback interface, the routing instance does not use a filter.
root@srx-2# show firewall 
filter A {
    term 1 {
        then {
            count A-rejected;
            reject;
        }
    }
}

root@srx-2# show interfaces lo0 
unit 0 {
    family inet {
        filter {
            input A;
        }
    }
}

}
Verification:
root@srx-1# run ssh 10.20.30.1

ssh: connect to host 10.20.30.2 port 22: Connection refused >>> rejected because of filter A applied in inet.0

[edit]

root@srx-1# run ssh 10.20.40.1

root@10.20.40.2's password: >>> accepted because of no filter applied on lo0.1 which belongs to test.inet.0 routing instance
Scenario 3:

If Filter A is configured on the default loopback interface, but the routing-instance loopback interface is not configured, the routing instance uses Filter A:
root@srx-2# show firewall 
filter A {
    term 1 {
        then {
            count A-rejected;
            reject;
        }
    }
}


root@srx-2# show interfaces lo0 
unit 0 {
    family inet {
        filter {
            input A;
        }
    }
}

}


Verification:
root@srx-1# run ssh 10.20.30.1

ssh: connect to host 10.20.30.2 port 22: Connection refused >>> rejected because of filter A applied in inet.0

[edit]

root@srx-1# run ssh 10.20.40.1

ssh: connect to host 10.20.40.2 port 22: Connection refused >>> rejected because there is no loopback interface in routing-instance test, which uses the filter A applied in default instance inet.0
Conclusion:

If a firewall filter is applied to lo0.0, it controls all of the access to the RE. If users want to access the RE for management via a routing instance, the default access will still be controlled via lo0.0. But the behavior may change, if another lo0.x is applied to the routing instance.

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