Hi Hisham,
elkadiki wrote:
Rule of thumb I give to my engineers is never trust the output of show security ike/ipsec sa or show interfaces st0.x terse after a simple commit. If the change isn't major it usually won't delete the SA so it will look as if the tunnel is up unless you have vpn-monitor.
Always ping across the tunnel while troubleshooting or do a "commit full" if you can afford disruption to firewall operations.
Yes,that true. Many times, I faced situation when tunnels were established in show sec associations but other end could not negotiate to set up a tunne 
I also noticed that SRX sometimes do not accept "commit". it might be one of the bugs.
Another interesting issue I noticed recently was that when you add to vpn policy: " establish tunnel imadiately " - and you configure that for one of several tunnels pointing to one devise ot all tunnels (for example subinterfaces) - tunels do not establish. My collegue had that problem and to solve that - we had to delete that command from all polices and recreate vpn polices from scratch as SRX could not negoitiate tunnel any more( no proposal choosen error).
In my opinion - delete problematic commands shoud be enouth to solve the issue - so Juniper TAC should look into that as well. Now we are looking to upgrade Junos - it is possible thta current one contains some bugs which might be fixed in higher release.