Unexpected Behavior with IPSec and PF's route-to

[Tube]

Given a typical (and established) IPSec-tunnel with
Phase 1: my-public-ip <-> remote-public-ip
Phase 2: my-internal-net <-> remote-internal-net

There are (simplified) these PF rules:
nat on my-puplic-interface from my-internal-net -> my-public-ip
pass in quick on my-internal-interface route-to (my-public-interface my-public-ip) from any to any

And of course there are two IPSec SPD-entries:
outgoing: my-internal-net > remote-interal-net  ESP my-public-ip -> remote-public-ip
incoming: remote-internal-net > my-internal-net ESP remote-public-ip -> my-public-ip

What now happens, when I send a packet from my-internal-ip (which is an IP inside my-internal-net)  to remote-internal-ip (an IP inside the remote-internal-net), is the remote side receives an ESP-packet which contains a packet from my-public-ip to remote-internal-ip.

That was a little bit unexpected to me, because there is no entry in the SP database which would match a packet from my-public-ip to remote-internal-ip.

So here's what I assume is happening:
When my packet enters the router it will somehow be tagged, that it has to enter the ESP-tunnel, because my packet matches the outgoing SPD-entry. Then PF goes into action, moves the packet to my-public-interface (because of route-to) and rewrites the source address, because of the nat rule. Then the packet is put into the ESP-tunnel, because it was tagged to enter ESP, and without checking the SPD again.

Is this the intended behavior? Or should the system check the packet against SPD again after rewriting?

[netcreator]

do you have valid configured ipsec network policies which describe which local-subnet can access an remote local-subnet?