user@host> show security flow session
…
Session ID. 41, Policy name: allow/5, Timeout: 20, Valid
In: 172.168.66.143/43886 –> 192.168.100.1/5000;tcp, If: ge-0/0/1.0, Pkts: 1, Bytes: 60
Out: 10.100.1.100/5555 –> 172.168.66.143/43886;tcp, If: ge-0/0/2.0, Pkts: 0, Bytes: 0
user@host> show configuration
…
security {
nat {
destination {
pool server {
address 10.100.1.100/32 port 5555;
}
rule-set rule1 {
from zone UNTRUST;
rule 1 {
match {
destination-address 192.168.100.1/32;
destination-port 5000;
}
then {
destination-nat pool server;
}}}}
proxy-arp {
interface ge-0/0/1.0 {
address {
192.168.100.1/32;
}}

}}
policies {
from-zone UNTRUST to-zone TRUST {
policy allow {
match {
source-address any;
destination-address any;
application [ junos-ping tcp-5000 ];
}
then {
permit;
}}}}
zones {
security-zone TRUST {
interfaces {
ge-0/0/2.0 {
host-inbound-traffic {
protocols {
all;
}}}}}
security-zone UNTRUST {
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
ping;
}}}}}}}
applications {
application tcp-5000 {
protocol tcp;
destination-port 5000;
}}

Your customer is attempting to reach your new server that should be accessible publicly using
192.168.100.100 on TCP port 5000, and internally using 10.100.100.1 on TCP port 5555. You notice a
session forms when they attempt to access the server, but they are unable to reach the server.
Referring to the exhibit, what will resolve this problem?

user@host> show log ibgp-trace
…
Jun 12 10:21:08 10:21:08.367627:CID-0:RT:192.168.2.1/49170->192.168.1.1/179;6> matched
filter ibgp-traffic:
Jun 12 10:21:08 10:21:08.367747:CID-0:RT:packet [64] ipid = 11792, @423f741c
Jun 12 10:21:08 10:21:08.367747:CID-0:RT:—- flow_process_pkt: (thd 2): flow_ctxt type 15,
common flag 0x0, mbuf 0x423f7200, rtbl_idx = 0
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: flow process pak fast ifl 71 in_ifp ge-0/0/3.0
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: ge-0/0/3.0:192.168.2.1/49170->192.168.1.1/179,
tcp, flag 2 syn
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: find flow: table 0x4f161150, hash 15898(0xffff), sa
192.168.2.1, da 192.168.1.1, sp 49170, dp 179, proto 6, tok 7
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: no session found, start first path. in_tunnel – 0,
from_cp_flag – 0
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: flow_first_create_session
Jun 12 10:21:08 10:21:08.367747:CID-0:RT:Doing DESTINATION addr route-lookup
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: routed (x_dst_ip 192.168.1.1) from trust (ge-0/0/3.0
in 0) to lo0.0, Next-hop: 92.168.1.1
Jun 12 10:21:08 10:21:08.367747:CID-0:RT:flow_first_policy_search: policy search from zone
trust-> zone loopback-zone (0x0,0xc01200b3,0xb3)
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: policy has timeout 900
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: app 0, timeout 1800s, curr ageout 20s
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: permitted by policy allow-bgp(8)
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: flow_first_install_session======> 0x5394a110
Jun 12 10:21:08 10:21:08.368250:CID-0:RT:flow_first_service_lookup(): natp(0x5394a110):
app_id, 0(0).
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: service lookup identified service 0.
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: flow_first_final_check: in 0/3.0>, out
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: existing vector list 2-49c75930.
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: Session (id:137) created for first pak 2
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: post addr xlation: 192.168.2.1->192.168.1.1.
Jun 12 10:21:08 10:21:08.368250:CID-0:RT:check self-traffic on lo0.0, in_tunnel 0x0
Jun 12 10:21:08 10:21:08.368250:CID-0:RT:retcode: 0xa01

Jun 12 10:21:08 10:21:08.368250:CID-0:RT:pak_for_self : proto 6, dst port 179, action 0x0
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: flow_first_create_session
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: flow_first_in_dst_nat: in , out A> dst_adr
192.168.1.1, sp 49170, dp 179
Jun 12 10:21:08 10:21:08.368752:CID-0:RT: chose interface lo0.0 as incoming nat if.
Jun 12 10:21:08 10:21:08.368752:CID-0:RT: packet droppeD. for self but not interested
Jun 12 10:21:08 10:21:08.368752:CID-0:RT: packet dropped, packet droppeD. for self but not
interested.
Jun 12 10:21:08 10:21:08.368752:CID-0:RT: flow find session returns error.
Jun 12 10:21:08 10:21:08.368752:CID-0:RT: —– flow_process_pkt rc 0x7 (fp rc -1)
You are asked to troubleshoot a new IBGP peering problem on your SRX Series device. The IBGP
peering is not establishing. Referring to the outputs in the exhibit, what is causing the problem?

user@host> show configuration
…
security {
nat {
destination {
pool server {
address 10.100.100.1/32 port 5555;
}
rule-set rule1 {
from zone UNTRUST;
rule 1 {
match {
destination-address 192.168.100.1/32;
destination-port 5000;
}
then {
destination-nat pool server;
}}}}
proxy-arp {
interface ge-0/0/1.0 {
address {
192.168.100.1/32;

}}}}
policies {
from-zone UNTRUST to-zone TRUST {
policy allow {
match {
source-address any;
destination-address any;
application [ junos-ping tcp-5000 ];
}
then {
permit;
}}}}
zones {
security-zone TRUST {
interfaces {
ge-0/0/2.0 {
host-inbound-traffic {
protocols {
all;
}}}}}
security-zone UNTRUST {
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
ping;
}}}}}}}
applications {
application tcp-5000 {
protocol tcp;
destination-port 5000;
}

}
Your customer is attempting to reach a new server that should be accessible publicly using
192.168.100.100 on TCP port 5000, and internally using 10.100.100.1 on TCP port 5555. You notice
no sessions form when the customer attempts to access the server. Referring to the exhibit, what
will resolve this problem?