Kernel decides route before executing ip_output()?

[Daniel Zebralla <daniel.zebralla%arcor.de@localhost>]

Hi,

is it possible that the Kernel looks at a packet (in my case ICMP ping
request) and already decides that he has no route to the target _before_
the function ip_output() is executed?
This question is related to my posting earlier this month
http://mail-index.netbsd.org/tech-net/2009/11/02/msg001703.html.
I still have the same setup:

Internal LAN <==> NetBSD-router <==IPSec-tunnel==> VPN-gw <==>
Corporate LAN

The router (running NetBSD 5.0-release) applies NAT on IPs in both
directions and communicates with the VPN-gw through an IPSec-connection
in tunnel mode.

I've added some printf-output to the ip_input()- and
ip_output()-functions printing source and destination addresses and
tried to ping from a client in the internal LAN to the
corporate-side-interface of the remote VPN-gw.
The result was that inside ip_input() ip->ip_src is the correct sender
and ip->ip_dst the correct destination address.

Inside ip_output() I've added the printf's right after the block for
filling in the IP header. I expected ip->ip_src and ip->ip_dst to be the
same as in ip_input(), because NAT (PFIL_HOOKS) and IPSec-policies are
applied later in this function.
The printf-output stated that ip->ip_src was now the IP of the
NetBSD-routers' internal interface and ip->ip_dst was the IP of the
pinging client because NetBSD generated an ICMP destination unreachable
message.
Of course this way NAT and IPSec can't be applied correctly which would
be necessary for the ping to be sent to its destination.

Is this habit correct and am I misunderstanding this process?
I'm glad to provide more information if needed.

PS: please CC me on any replies as I'm not yet subscribed to this list.

Thank you
 - Daniel