Description

This article describes the issue of host inbound restrictions not working as expected, when accessing an interface via multiple routing-instances.

Symptoms

 Topology:

SSH client -----> reth5.29 (Test1 routing-instance) ----->reth6.0 (inet.0 or another routing-instance)
Configuration:

Ingress interface:
set interfaces reth5 vlan-tagging
set interfaces reth5 redundant-ether-options redundancy-group 1
set interfaces reth5 unit 29 description incoming-ssh-interface
set interfaces reth5 unit 29 vlan-id 29
set interfaces reth5 unit 29 family inet address 192.168.131.108/24

Egress interface:
set interfaces reth6 redundant-ether-options redundancy-group 1
set interfaces reth6 unit 0 family inet address 172.27.208.1/24

Host-inbound restrictions:
set security zones security-zone test1 host-inbound-traffic system-services ping
set security zones security-zone test1 host-inbound-traffic system-services traceroute
set security zones security-zone test1 interfaces reth5.29

set security zones security-zone test2 host-inbound-traffic system-services ping
set security zones security-zone test2 interfaces reth6.0

Routing-instance:
set routing-instances test1 instance-type virtual-router
set routing-instances test1 interface reth5.29
set routing-instances test1 routing-options instance-import accept_from_inet0

set policy-options policy-statement accept_from_inet0 term t1 from instance master
set policy-options policy-statement accept_from_inet0 term t1 from route-filter 172.27.208.0/21 orlonger
set policy-options policy-statement accept_from_inet0 term t1 then accept
set policy-options policy-statement accept_from_inet0 term t2 then reject

From the configuration, SSH is not permitted as per the host-inbound perspective. However, in such a scenario, you can see that SSH is working.

TCP dump on the client shows that SSH is working:

15:23:24.087286 Out IP truncated-ip - 10 bytes missing! 192.168.131.109.54219 > 172.27.208.1.ssh: S 1765664066:1765664066(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp[|tcp]>
15:23:24.096042 In IP truncated-ip - 14 bytes missing! 172.27.208.1.ssh > 192.168.131.109.54219: S 2720888258:2720888258(0) ack 1765664067 win 65535 <mss 1460,nop,wscale 1,nop,nop,[|tcp]>
15:23:24.096225 Out IP 192.168.131.109.54219 > 172.27.208.1.ssh: . ack 1 win 33304 <nop,nop,timestamp 612605833 345154035>
15:23:24.233608 In IP truncated-ip - 23 bytes missing! 172.27.208.1.ssh > 192.168.131.109.54219: P 1:22(21) ack 1 win 33304 <nop,nop,timestamp 345154172[|tcp]>
15:23:24.234486 Out IP truncated-ip - 18 bytes missing! 192.168.131.109.54219 > 172.27.208.1.ssh: P 1:21(20) ack 22 win 33304 <nop,nop,timestamp 6126</code>

Note : This applies only to interfaces which are in routing-instances and access to the interface is from a different routing-instance .

Solution

For traffic destined only to the SRX, in the event that the destination interface is not in the same routing-instance as the ingress interface, the SRX permits this traffic without the check of whether the packets are interested by the interface (which is the host-inbound-traffic configuration).

This issue would only apply to a situation in which:

  • The ingress interface is in a non-inet0 routing-instance.
  • The destination interface is in a different routing-instance from the ingress interface or inet.0.

 The workaround for this issue is to apply a firewall filter to limit access to the SRX device.

An example for the above mentioned config would be:

set interfaces lo0 unit 0 family inet filter input protect-RE

set firewall family inet filter protect-RE term management-access from source-address 0.0.0.0/0
set firewall family inet filter protect-RE term management-access from destination-address <A.A.A.A>
set firewall family inet filter protect-RE term management-access from protocol tcp
set firewall family inet filter protect-RE term management-access from destination-port ssh
set firewall family inet filter protect-RE term management-access then accept

Where A.A.A.A are IP addresses on the SRX, to which management access should be permitted:
set firewall family inet filter protect-RE term allow-nothing-else then count reject-counter
set firewall family inet filter protect-RE term allow-nothing-else then log
set firewall family inet filter protect-RE term allow-nothing-else then syslog
set firewall family inet filter protect-RE term allow-nothing-else then discard

To verify if the firewall filter is working, the firewall filter will log entries to show the traffic to the RE (routing engine has been denied):
{primary:node0}
root@SRX3400-50> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
13:54:45 pfe D reth5.29 TCP 192.168.131.109 172.27.208.1
13:54:42 pfe D reth5.29 TCP 192.168.131.109 172.27.208.1
13:50:31 pfe D reth5.29 TCP 192.168.131.109 172.27.208.1

Also, take note that applying a firewall filter to the loopback interface should be carefully considered, as protocols such as BGP and IKE, also need to be permitted. For more information about applying firewall filters to loopback interfaces, refer to the following link:

www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-applying-firewall-filters-to-interfaces.html

This issue will be fixed with the following releases - 11.2R7, 11.4R4, 12.1R3, 12.2R1, and 10.4R11.