Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sonicwall to Sophos IPSEC stays down after rekey

I have a sonicwall nsa2400 connecting to my UTM running 9.3.x.

The tunnel comes up fine and I pass traffic... for a while. It seems like about the time it rekeys, the tunnel drops and most never comes back up.

I see messages like this in the Sonicwall:

RECEIVED>>> ISAKMP OAK INFO (InitCookie:0xefa89df1ea03dad5 RespCookie:0x5952a2256c190756, MsgID: 0x2E84E656)  (NOTIFY: PAYLOAD_MALFORMED)
IKE negotiation aborted due to Timeout

(BTW, I know the PSK is good because the tunnel works fine for a period of time).

On the UTM side, I see these:
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: initiating Main Mode to replace #20284
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: ignoring Vendor ID payload [5b362bc820f60008]
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: received Vendor ID payload [RFC 3947]
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: enabling possible NAT-traversal with method 3
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: ignoring Vendor ID payload [404bf439522ca3f6]
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: received Vendor ID payload [XAUTH]
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: received Vendor ID payload [Dead Peer Detection]
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: NAT-Traversal: Result using RFC 3947: no NAT detected
2015:08:19-14:59:46 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: Informational Exchange message must be encrypted
2015:08:19-14:59:54 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: discarding duplicate packet; already STATE_MAIN_I3
2015:08:19-14:59:56 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: Informational Exchange message must be encrypted
2015:08:19-15:00:03 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: discarding duplicate packet; already STATE_MAIN_I3
2015:08:19-15:00:56 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message
2015:08:19-15:00:56 utm-1 pluto[6671]: "S_REF_IpsSitCmsCorp_1"[1] xx.xx.xx.78 #20294: starting keying attempt 107 of an unlimited number

Every once in a blue moon it'll reestablish, but I usually have to go into the sonicwall and disable/enable the tunnel for it to restablish.

If it matters, the UTM is in respond-only mode. 
IKE: main mode/ dh group 5/aes-256/sha256/7800 timeout
IPSec: ESP/aes-256/sha256/3600 timeout
PFS is not enabled.
DPD is enabled on both sides.
I have "enable keep alive" set on sonicwall.

Any ideas?


This thread was automatically locked due to age.
Parents
  • In case anyone happens upon this thread with the same issue, increasing the timeouts to 86400 on both SA lifetimes seems to have done the trick. Not sure why, but it's been stable since increasing those.
Reply
  • In case anyone happens upon this thread with the same issue, increasing the timeouts to 86400 on both SA lifetimes seems to have done the trick. Not sure why, but it's been stable since increasing those.
Children