SRX

I understand that for transit traffic to pass from a zone to another zone , the incoming zone must have the host-inbount-traffic enabled for that specific traffic.

I have an SRX 650 with the following config on the untrust zone :

root@UTM# run show version 
Hostname: UTM
Model: srx650
JUNOS Software Release [11.2R4.3]

[edit]
root@UTM# show security zones security-zone untrust 
address-book {
    address remote_vpn 172.24.1.24/32;
}
screen untrust-screen;
interfaces {
    ge-0/0/1.0 {
        host-inbound-traffic {
            system-services {
                ike;
                ssh;
            }
        }
    }
}

[edit]
root@UTM# run show interfaces ge-0/0/1.0 
  Logical interface ge-0/0/1.0 (Index 70) (SNMP ifIndex 514) 
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Input packets : 5249268652 
    Output packets: 4559739467
    Security: Zone: untrust
    Allowed host-inbound traffic : ike ssh
    Protocol inet, MTU: 1500

Although i have only ssh and ike enabled on the interface , users can still http to the Trust zone as per the policy configured. 

I just need to understand the behaviour of Junos in such case.  I thought that even if policy permits it , the service must still be enabled on the zone ?

Thanks alot in advance.

Hi,

Host-inbound traffic applies to the final destination zone. A policy from the incoming to the destination zones must allow the traffic. In 11.4 things change Copy from release notes:

•

Security policies for self-traffic—This feature is supported on all branch SRX Series

and J Series devices.

Users can now configure security policies for the self-traffic (the host inbound traffic

or the host outbound traffic) of the device. The user can further apply relevant services

to the new self-traffic policy.

The security policies for the self-traffic are configured under the new default security

zone called

junos-host zone.

[

Junos OS CLI Reference, Junos OS Security Configuration Guide]

thanks for your reply.

can you please check the attachment and the config for the trust zone :

root@UTM# show security zones security-zone trust 
address-book {
    address local_vpn 10.35.18.91/32;
    address 10.35.18.91/32 10.35.18.91/32;
    address 192.168.56.37 192.168.56.37/32;
}
screen untrust-screen;
interfaces {
    ge-0/0/3.0;
    ge-0/0/0.0 {
        host-inbound-traffic {
            system-services {
                ssh;
            }
            protocols {
                all;
            }
        }
    }
}

I don't have http enabled in the trust zone (destination zone )  either , if that's what you mean.

---

@abdullah_marji@emitac.com.jo wrote:

I understand that for transit traffic to pass from a zone to another zone , the incoming zone must have the host-inbount-traffic enabled for that specific traffic.

---

As Screenie stated, the host-inbound-traffic option must be enabled on the destination-zone interface , and you must have policy from source-zone to destination-zone to permit it as well when you crossing firewall zones to reach it. 

Please note that the new feature in 11.4 is useful "in addition" to this, but not required.  If you're familiar with using a 'protect-re' filter on the loopback interface to provide additional restrictions on who can ssh in, use snmp, etc, the 11.4 feature provides a stateful feature to do that.

Prior to this, if you enabled 'host-inbound-traffic system-services ssh/snmp/ping", you could not further restrict *who* was allowed to ssh/snmp poll/ping without using a firewall filter on lo0.

Regards,

Joel

Dear Abdullah,

Just to make sure you are talking about transit traffic target destination hosts not the Trust zone interfaces IP address (ge-0/0/3 & ge-0/0/0). Because if you are trying to access the SRX via http as per your configuration it is not allowed but if you like to access server in your LAN for example you could.

The attached snapshot you included host.jpg is the flow chart if the traffic destination is any interface other than the incoming interface.

Thanks,

Mohamed Elhariry

JNCIE-M/T # 1059, CCNP & CCIP

Thanks Mohamed 🙂