On Wed, 26 Aug 2015, Lennart Sorensen wrote:
Aug 5 14:50:13 ruggedcom pluto[8239]: "Test" #3: ignoring Delete SA payload:
PROTO_IPSEC_ESP SA(0xbd111c17) not found (our SPI - bogus implementation)
Aug 5 14:50:13 ruggedcom pluto[8239]: "Test" #3: received and ignored
informational message
Ahhh. maybe this is the source of the problem. We are not deleting the
IPsec SA because they used the wrong SPI number to send the delete.
I guess we could use our spi to lookup their spi, and if we find
something that's covered under the same ISKAMP SA (eg st_clonedfrom)
then delete it anyway.
192.168.30.0/24===192.168.10.1<192.168.10.1>[+S=C]...192.168.10.2<192.168.10.2>[+S=C]===192.168.20.0/24;
prospective erouted; eroute owner: #0
000 #4: "Test":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 3143s; isakmp#3; idle; import:not set
000 #4: "Test" [email protected] [email protected]
[email protected] [email protected] ref=0 refhim=4294901761
000 #3: "Test":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in 3142s; newest ISAKMP; lastdpd=52s(seq in:0 out:0); idle;
import:not set
000 #2: "Test":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 3072s; isakmp#1; idle; import:not set
000 #2: "Test" [email protected] [email protected]
[email protected] [email protected] ref=0 refhim=4294901761
000 #1: "Test":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in 3071s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
Although why am I not seeing the spi 0xbd111c17 anywhere? Does your bug
report have more plutologs that we can trace down 0xbd111c17 and see if
this is indeed an ESP SPI and not an ISAKMPD SPI?
Debug on cisco suggesting that RC device is responding to DPD message with
correct sequence number even when the tunnel is in the state of "Prespective
erouted"
Well, the ISAKMP SA is still up, so it should?
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
