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?

A.
There must be a TRUST-to-UNTRUST security policy to allow return traffic.

B.
The NAT pool server address must be changed to 10.100.100.1/32.

C.
The NAT pool server port must be changed to 5000.

D.
The NAT rule set rule1 must match on address 172.168.66.143.