OSPF on the move? Include a Forwarding Address

I enjoyed Petr's article regarding explicit next hop.  It reminded me of a scenario where a redistributed route, going into OSPF conditionally worked, depending on which reachable next hop was used.

Here is the topology for the scenario:

Here is the relevant (and working :)) information for R1.

When we replace the static route, with a new reachable next hop, we loose the ability to ping 100.100.100.3

When we change the next hop for the static route, (which is being redistributed into OSPF), the route to 100.100.100.0/24 no longer works, even though we have verified ability to ping the new next hop.

Can you solve this puzzle?  Please post your ideas!

For more troubleshooting scenarios, please see our CCIE Route-Switch workbooks, volume 2, for more than 100 challenging troubleshooting scenarios.

We will post the results right here, in a few days, after you have had a chance to post your comments and ideas.

Best wishes.

Follow-up-

Thank you for all the great answers, (below in the comments).

R1, using a next hop of 172.16.33.33 in its static route, will include that same address in the LSA as the forwarding address.  Among the requirements that make this possible, the one we are going to focus on here is that this next hop is in the same IP subnet as an OSPF interface (Lo0) on R1.  172.16.1.1/16 (R1) and 172.16.33.33 (next hop address, owned by R3).

If we use a next hop that isn't in the same IP subnet as an OSPF interface on R1, the LSA will not include the next hop forwarding address, which will then cause R2 to believe that R1 is the next hop and the route will fail to work.   We could also cause the 0.0.0.0 to show up by changing the ospf network type for R1 Loop 0 to point-to-point, not including Loop 0 in the network statement for OSPF, or by setting Loop 0 as a passive interface for OSPF. (take your pick) :)

Again, thanks to all for the EXCELLENT answers and insights.

You rock!