Ping – ‘Destination Host Unreachable’ When Pinging a PC from Another Network

Since Router 1 is on an outside interface of Router 2, it will not be able to originate traffic to the inside of Router 2. You have configured inside source NAT on Router 2, and this is one-way. Addresses are translated from the inside to the outside. When traffic is originated from the inside, NAT creates a table entry in order for responding traffic to be translated, but it has no table entry for traffic originated from the outside.

Running NAT on links where you are running a routing protocol is a very bad idea.

Edit based on your updated information:

If you need or want the firewall to know about the routes on the other side of Router 2, you will need to somehow get the routes into the firewall's routing table, otherwise any traffic for the unknown networks will be sent toward the default route for the firewall, and that should be the WAN.

A router, including the routing process of your firewall, needs to have a route in its routing table for any network to which it is expected to forward traffic. A default route can be used to encompass all networks, and any more specific routes in the routing table are used. Since your firewall's routing table has no routes to the networks on the other side of Router 2, it will use its default route.

You can configure your firewall to participate in OSPF with your two routers, and that will place those routes in the firewall's routing table. It will also let you originate the default route into OSPF from the firewall, and then you should remove that from the other routers.

The other, less desirable, solution is to manually configure static routes in your firewall for the networks to which it has no direct connection. This doesn't scale, and when you add, remove, or change those networks, you will need to manually change the static routes in the firewall.

First we need to understand how packets are sent.

When a host or router tries to send an IPv4 packet* it first looks up the destination in it's routing table. Based on the routing table it determines the "next hop IP address" and interface. For a machine on a local subnet the "next hop IP address" will be the IP address of the destination, otherwise it will be the IP of a gateway.

What happens next depends on the interface type. Assuming it's an Ethernet or similar interface the network stack needs to determine what MAC address to send the packet to. To do that it looks up the "next hop IP address" in the ARP table for the interface. If it finds a valid entry then it fills in the MAC address and sends the packet out over the Ethernet interface.

If it doesn't find a valid ARP table entry then it will begin the ARP process to try and create one. In the meantime packets destined for that next-hop IP address will be queued up until the system knows what MAC address to send them too.

If the ARP process times out then on many platforms, any queued up packets will be rejected with a "destination host unreachable" ICMP message (some platforms just silently drop the packets).

Eventually entries in the ARP table time out and need to be refreshed.

On hosts/routers without a default gateway you can also get a "destination host unreachable" reply generated if there is no routing table entry, so the system doesn't even know what interface to ARP on.

So what happens when you power cycle a machine and ping it?

At first you likely already have a valid ARP table entry. Your machine puts the packets on the wire but they never get delivered because the network stack on the destination is down. You get "Request timed out" (with microsoft ping, linux ping doesn't display the lack of response at all).

Later the ARP cache entry times out. The hop before the box you power cycled (may be your client box or a router) tries to do a new ARP lookup but fails, so it bounces the packets with ICMP errors. Often you see multiple packets get queued up and bounced at the same time.

Finally the network stack on the target box comes back up. ARP succeeds and the packets are sent to the target which replies to them.

* With IPv6 the principles are similar but the details are different.