1:1 NAT does not work properly behind a Site2Site IPsec tunnel

MeisterBlocker

Network Company:

WAN x.x.x.x
LAN 10.100.254.9 - IPv4 Upstream gateway: 10.100.254.10
OPTINT 192.168.100.100/20 (not important now)
IPSEC Site2Site
route to 10.224.0.0/13 over 10.100.254.10 (This is a separate hardware firewall to connect to the many branch offices.)

Service provider for our branch offices:

IPSec connection, Remote network: 192.168.44.0/24

Default IPSec:

Phase2: Local = 10.224.0.0/13, NAT/BINAT translation = none, Remote Network = 10.49.205.19/32

That works so far. We now have the problem that the service provider can no longer manage such a large subnet, as the network overlaps with other customers.
The question arose as to whether we could reduce the size of the network and then pass it on to subnets via NAT. In the branch offices, only the subnet is important: 10.x.x.64/29. I therefore thought that I could solve this via a second phase2 in the ipsec tunnel and then define a NAT 1:1.

Added in our Company pfSense:

second Phase2: Local = 10.12.0.0/18, NAT/BINAT translation = none, Remote Network = 192.168.44.0/24
Firewall->NAT->1:1: Interface = IPSEC, External subnet IP = 10.12.0.8, Internal IP = 10.227.230.64/29, Destination = 192.168.44.0/24

Unfortunately, it does not work completely. We assume that the pfSense firewall allows everything on all interfaces except the WAN connection.
If the service provider sends a ping to the host 10.227.230.66, the ping also arrives there and is sent back to the sender. However, the response does not come from the correct source and is therefore not sent back through the IPsec tunnel.

service provider: host with 192.168.44.11 ping to 10.12.0.10
icmp goes through the IPsec tunnel to our firewall
pfsense changes the destination address to 10.227.230.66
ping is routed to the firewall: 10.100.254.10
ping continues via the VPN to the remote site
the host 10.227.230.66 receives the ping
response from the ping (echo reply) is sent to 192.168.44.11
ping goes through the tunnel to our firewall
pfsense receives the packet and cannot allocate it and therefore wants to send it to the WAN interface. The ping now has the source 10.227.230.66 which should actually be changed back to 10.12.0.8. Unfortunately this does not work and therefore the packet is not sent into the IPsec tunnel.

Packet capture on service provider side:

18:20:06.058525 (authentic,confidential): SPI 0xc5fc2660: IP 192.168.44.11 > 10.12.0.10: ICMP echo request, id 1, seq 4913, length 40
18:20:11.059172 (authentic,confidential): SPI 0xc5fc2660: IP 192.168.44.11 > 10.12.0.10: ICMP echo request, id 1, seq 4914, length 40

Packet capture on company side LAN interface:

18:32:20.127053 IP 192.168.44.11 > 10.227.230.66: ICMP echo request, id 1, seq 5048, length 40
18:32:20.149834 IP 10.227.230.66 > 192.168.44.11: ICMP echo reply, id 1, seq 5048, length 40
18:32:25.127585 IP 192.168.44.11 > 10.227.230.66: ICMP echo request, id 1, seq 5049, length 40
18:32:25.150124 IP 10.227.230.66 > 192.168.44.11: ICMP echo reply, id 1, seq 5049, length 40

Packet capture on company side IPsec interface: (You can see that there is no reply here.)

18:20:06.058525 (authentic,confidential): SPI 0xc5fc2660: IP 192.168.44.11 > 10.12.0.10: ICMP echo request, id 1, seq 4913, length 40
18:20:11.059172 (authentic,confidential): SPI 0xc5fc2660: IP 192.168.44.11 > 10.12.0.10: ICMP echo request, id 1, seq 4914, length 40

Packet capture on company side WAN interface:

18:33:40.157462 IP 10.12.0.10 > 192.168.44.11: ICMP echo reply, id 1, seq 5064, length 40
18:33:45.157529 IP 10.12.0.10 > 192.168.44.11: ICMP echo reply, id 1, seq 5065, length 40

WTF? Why is the packet sent to the WAN interface and not the IPSec tunnel?
Since it is not possible to configure a static route for an IPsec tunnel, the signal does not reach the sender.