Hi there,
1stly, Your Shrew side timestamps are way off which makes it extremely difficult to analyse:
15/05/11 20:55:32 ii : received peer DELETE message
15/05/11 20:55:32 ii : - 10.90.3.25:500 -> 10.90.3.53:500
15/05/11 20:55:32 ii : - isakmp spi = 9db9e285a948b664:77011ca392420f1f
Same from SRX side:
[May 13 00:20:41]ssh_ike_tunnel_table_entry_delete: Deleting tunnel_id: 0 from IKE tunnel table
[May 13 00:20:41]ssh_ike_tunnel_table_entry_delete: The tunnel id: 0 doesn't exist in IKE tunnel table
[May 13 00:20:41]ike_sa_delete: Start, SA = { 9db9e285 a948b664 - 77011ca3 92420f1f }
The timestamps are off by ~27.5 hours which cannot be explained by timezone difference.
If You want to be helped, please make it easier to others, not harder.
Anyway, now You have a different problem and Shrew is at fault because it ignores CFG messages and does not respond with anything at all, hence SRX deletes the IKE SA on no reply after 5 retransmits.
SRX side:
[May 13 00:19:51]ike_retransmit_callback: Start, retransmit SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2
[May 13 00:19:51]ike_send_packet: Start, retransmit previous packet SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2, dst = 10.90.3.53:500 routing table id = 0
[May 13 00:20:01]ike_retransmit_callback: Start, retransmit SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2
[May 13 00:20:01]ike_send_packet: Start, retransmit previous packet SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2, dst = 10.90.3.53:500 routing table id = 0
[May 13 00:20:11]ike_retransmit_callback: Start, retransmit SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2
[May 13 00:20:11]ike_send_packet: Start, retransmit previous packet SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2, dst = 10.90.3.53:500 routing table id = 0
[May 13 00:20:21]ike_retransmit_callback: Start, retransmit SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2
[May 13 00:20:21]ike_send_packet: Start, retransmit previous packet SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2, dst = 10.90.3.53:500 routing table id = 0
[May 13 00:20:31]ike_retransmit_callback: Start, retransmit SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2
[May 13 00:20:31]ike_send_packet: Start, retransmit previous packet SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2, dst = 10.90.3.53:500 routing table id = 0
[May 13 00:20:41]ike_retransmit_callback: Start, retransmit SA = { 9db9e285 a948b664 - 77011ca3 92420f1f}, nego = 2
[May 13 00:20:41]ike_retransmit_callback: Isakmp query retry limit reached, deleting
Shrew side:
15/05/11 20:54:42 <- : recv IKE packet 10.90.3.25:500 -> 10.90.3.53:500 ( 92 bytes )
15/05/11 20:54:42 DB : phase1 found
15/05/11 20:54:42 ii : processing config packet ( 92 bytes )
15/05/11 20:54:42 DB : config found
15/05/11 20:54:42 !! : config packet ignored ( config already mature )
15/05/11 20:54:52 <- : recv IKE packet 10.90.3.25:500 -> 10.90.3.53:500 ( 92 bytes )
15/05/11 20:54:52 DB : phase1 found
15/05/11 20:54:52 ii : processing config packet ( 92 bytes )
15/05/11 20:54:52 DB : config found
15/05/11 20:54:52 !! : config packet ignored ( config already mature )
15/05/11 20:55:02 <- : recv IKE packet 10.90.3.25:500 -> 10.90.3.53:500 ( 92 bytes )
15/05/11 20:55:02 DB : phase1 found
15/05/11 20:55:02 ii : processing config packet ( 92 bytes )
15/05/11 20:55:02 DB : config found
15/05/11 20:55:02 !! : config packet ignored ( config already mature )
15/05/11 20:55:12 <- : recv IKE packet 10.90.3.25:500 -> 10.90.3.53:500 ( 92 bytes )
15/05/11 20:55:12 DB : phase1 found
15/05/11 20:55:12 ii : processing config packet ( 92 bytes )
15/05/11 20:55:12 DB : config found
15/05/11 20:55:12 !! : config packet ignored ( config already mature )
15/05/11 20:55:22 <- : recv IKE packet 10.90.3.25:500 -> 10.90.3.53:500 ( 92 bytes )
15/05/11 20:55:22 DB : phase1 found
15/05/11 20:55:22 ii : processing config packet ( 92 bytes )
15/05/11 20:55:22 DB : config found
15/05/11 20:55:22 !! : config packet ignored ( config already mature )
Few minutes of Googling brought me this nugget where Shrew developer initially blames JNPR but then agrees to rewrite own code
https://lists.shrew.net/pipermail/vpn-help/2012-December/009381.html
HTH
Thanks
Alex