Ipsec to cisco asa 5506 failing (corrected)

[sorry, last version was posted too soon.]
it looks like the cisco stops responding and restarts the connection. the connection restart breaks SSH and RDP connections.

Feb 4 11:33:42 ipfire charon: 15[ENC] generating INFORMATIONAL response 17 [ ]
Feb 4 11:33:42 ipfire charon: 15[NET] sending packet: from yy.yy.yy.yy[4500] to xx.xx.xx.xx[4500] (96 bytes)
Feb 4 11:33:47 ipfire charon: 09[IKE] giving up after 5 retransmits
Feb 4 11:33:47 ipfire charon: 09[IKE] proper IKE_SA delete failed, peer not responding
Feb 4 11:33:47 ipfire vpn: client- xx.xx.xx.xx 192.168.10.0/24 == xx.xx.xx.xx – yy.yy.yy.yy. == 192.168.20.0/24
Feb 4 11:33:47 ipfire vpn: tunnel- xx.xx.xx.xx – yy.yy.yy.yy
Feb 4 11:33:47 ipfire ipsec: Creating route to 192.168.10.0/255.255.255.0 (via 192.168.20.1 and red0)
Feb 4 11:33:47 ipfire ipsec: Creating route to 192.168.9.0/255.255.255.0 (via 192.168.20.1 and red0)
Feb 4 11:33:47 ipfire charon: 16[CFG] rereading secrets

any suggestions as to what to look at?

Clearly the remote end was no longer reachable any more.

Either it lost connectivity or the IPsec stack on the other side crashed. There is most likely nothing wrong with your configuration.

This leaves us with an interesting situation that Cisco IPSec and IPFire IPSec have an incompatibility. I found out from one of the text later that Cisco is reporting timeouts and the next go around is going to involve checking rekeying times but in theory the protocol should be able to handle one side with a shorter rekeying time time than the other.

I’ll try to get the IPFire to IPFIre failure I spoke about captured sometime the next day or two.

It could simply be an Intrusion Prevention System jumping in and mis-classifying packets…

Interesting. I never would’ve thought of that. Thank you for another thing to investigate.

1 Like