I just resolved this EXACT issue - and the problem was with the SRX, not the SSG...
With me, I am terminating my SRX tunnel (gateway) on a loopback interface w/ a private IP.
The tunnel is in dynamic mode, not main mode; as well as a policy-based vpn, not route-based.
The lo0.0 interface simply sources the IKE Phase1 and Phase2 requests to the SSG out whichever physical RETH the default-route is using.
(For reasons I have yet to ascertain, the traffic sourced from the lo0 interface and leaving the RETH interface gets NAT'd to the RETH's public IP without having to use a security nat source rule-set. Beats me... but I digress....)
Due to the fact that the only way you can use a lo0 interface as an IKE gateway interface for your tunnel, it has to reside within the same security-zone as the physical RETH being used for default-routing. In this case, both interfaces are in the untrust-zone.
Running IKE debugs on the SSG confirmed that Phase1 and Phase2 were being received by the SSG; AND the SSG was sending Phase2 back to the SRX.
However, by default, the SRX blocks intra-zone traffic, thus the Phase2 session FROM the SSG was being dropped by the SRX. Remember, Phase 2 is BI-DIRECTIONAL - that's why there are 2 SAs for Phase2 but only 1 SA for Phase1.
The Solution:
set security policies from-zone untrust to-zone untrust policy intra-untrust match source-address any
set security policies from-zone untrust to-zone untrust policy intra-untrust match destination-address any
set security policies from-zone untrust to-zone untrust policy intra-untrust match application any
set security policies from-zone untrust to-zone untrust policy intra-untrust then permit
My tunnel is now up.
I think this error is basically the SSGs way of saying, "Hey, I already got a Phase2 from you, and I spawned the bi-directional response back . . . but now you're sending me another - I don't need it, I already have the 1st one (preexisting).
If the SSG had a personality like mine, it would say, "Hey, if you'd just permit my Phase2 session to transit from your public RETH to your lo0.0 interface using an intra-zone permit policy, we wouldn't be having this issue!
Hope that helps!