You are a network engineer for a company that has just deployed a Juniper SRX firewall in a branch office. The device has multiple interfaces: ge-0/0/0 connected to the internet, ge-0/0/1 connected to the internal LAN (192.168.1.0/24), and ge-0/0/2 connected to a DMZ (10.0.0.0/24). After initial configuration, you attempt to ping from the SRX to a server on the internet (8.8.8.8) but receive no response. You also notice that internal users can access the internet. You have verified the routing table shows a default route via ge-0/0/0. The security policies appear correct. You suspect the issue is related to interface configuration. What is the most likely cause and the correct course of action?
This is the most likely cause because the device cannot initiate traffic without explicit host-inbound traffic settings.
Why this answer
The SRX can ping internal hosts but not the internet because the interface ge-0/0/0 is in the untrust zone, which by default blocks all inbound traffic, including pings originated from the device itself. The 'host-inbound-traffic' configuration under the security zone allows system services such as ping, SSH, and SNMP to be received on that interface. Without it, even though the routing table and security policies are correct, the SRX will drop its own outbound ICMP echo requests before they can be sent, or drop the replies if they are treated as inbound traffic.
Exam trap
The trap here is that candidates confuse transit security policies (which control traffic passing through the device) with host-inbound traffic controls (which manage traffic destined to the device itself), leading them to incorrectly modify security policies instead of enabling system services under the zone.
How to eliminate wrong answers
Option A is wrong because the security policy from trust to untrust controls traffic passing through the SRX, not traffic originated from the SRX itself; device-originated traffic is governed by the 'host-inbound-traffic' settings, not security policies. Option B is wrong because an incorrect MAC address would cause a failure to resolve the next-hop MAC, which would prevent all traffic (including internal users) from reaching the internet, but internal users can access the internet, so ARP is working. Option D is wrong because the routing table already shows a default route via ge-0/0/0, and internal users can access the internet, confirming the default route is correct.