Hi spuluka,
Yes this route is also used to reach the internet, it will certainly be used to reach the remote VPN gateway. But it is also used when the local gateway receives the first packet of a flow destined to the remote subnets. By remote subnets I mean the subnets reachable via the IPsec VPN.
When the local VPN gateway receives the first packet of a flow destined to the remote subnet, it will
1) Do a route a lookup to find the egress security zone.
2) Thanks to this route, it will know that the egress security zone is "untrust".
3) Then it can check the security policies "from-zone Z to-zone untrust"
4) It finds the policy allowing such traffic via the IPsec tunnel "then permit tunnel pair-policy vpn-untrust-1"
If point 2) fails, then the SRX cannot chek points 3) and 4)
Check this post that states exactly what I am trying tio explain
On the opposite direction, something equivalent is necessary but only for traffic initiated remotely.
And this is because if the traffic is initiated locally, the return packet that hits the remote SRX will not require a route lookup as there is already a session for the flow. The only requirement is that the return traffic hits the remote SRX on the same security zone as the initial packet left it.
Coming back to the initial problem, I beleive we need to troubleshoot on the remote peer.