ipfw -- why need to let icmp out that I already let in?

[freebsd at dreamchaser.org]

I'm now running 6.1 using PPPoE through a bridging DSL modem.
Using ipfw

I have the following rules regarding for ping / traceroute:

oip, oif are the outside tun0 ip addr and interface
inet, imask, and iif are the internal netip/mask/interface

from ipfw.conf:

# Allow pings out
#  Note that for internal machines, this is an INCOMING request on the INTERNAL interface.
add 10510 allow icmp from any to any out via oif() keep-state
add 10511 allow icmp from inet():imask() to any in via iif() keep-state

# Allow traceroute
#  Note that for internal machines, this is an INCOMING request on the INTERNAL interface.
#  Note the need to relay letting the icmp replies back out the internal interface in 10532!
add 10520 allow udp from oip() to any out via oif() keep-state
add 10521 allow icmp from any to oip() in via oif() icmptypes 3,11
add 10530 allow udp from inet():imask() to any in via iif() keep-state
add 10531 allow icmp from any to inet():imask() in via oif() icmptypes 3,11
add 10532 allow icmp from any to inet():imask() out via iif() icmptypes 3,11

My question is regarding entry 10532.
Without it, packets for traceroute come in on iif and are routed out on oif,
but the returning icmp time exceeded in-transit packets are
not forwarded to the internal network; they come in on oif (line 10531)
but never go out on iif.
Why is 10532 necessary?  Other requests from the internal network,
such as http requests, get forwarded out the other interface just fine,
and returning packets are routed back to the internal interface,
with a single entry of the form:

add 10220 allow tcp from inet():imask() to any http in via iif() setup keep-state

When dynamic rules are built, are they built for all interfaces to allow
a packet to go anywhere appropriate, and similarly for return packets?
Is the above only a problem because of the stateless nature of icmp?
I assumed that if I allowed a packet in,
it would be allowed out to its destination automatically.

Gary