An engineer traces a failed sync from 10.4.18.7 to 10.9.2.41 on TCP 5432 with the FMC packet tracer. The output shows the interface and access control phases passing on an allow rule, yet the trace ends in a drop with the reason no route to host, and the device routing table holds only directly connected networks. Which change resolves the routing drop reported by the packet tracer?
Select an answer to reveal the explanation.
Short Explanation
You can see that the interface and access-control phases pass, so the allow rule is not the issue. The routing lookup has no path to the destination network, like a GPS with no map entry for that street. Adding a static route through the internal next hop gives the firewall that path.
Full Explanation
The packet tracer passes the interface and access-control phases, then reports “no route to host.” That points to a missing forwarding entry on the firewall, not a blocked TCP port or a failed policy decision. A static route for 10.9.2.0/24 through the internal next hop installs a matching route in the firewall’s routing table, allowing it to forward packets for 10.9.2.41. A host route installed on the internal router affects that router’s forwarding decisions, not the firewall’s; the trace shows that the firewall lacks a route. Enabling OSPF can learn remote networks, but it helps only if the firewall forms an adjacency and receives the destination prefix; configuring the protocol alone does not supply the missing entry. Identity NAT can preserve addresses for traffic that should not be translated, but it changes address handling rather than adding a route, so the firewall would still lack a forwarding match. Exam caveat: OSPF can provide the needed route when an adjacency is established and the prefix is learned, but the stated routing table has only directly connected networks. Practical check: after adding the static route, inspect the firewall’s routing table for 10.9.2.0/24 and rerun packet tracer to confirm the route lookup and next-hop interface.