Description

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.

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

[email protected]'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

[email protected]'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.