[vpn-help] INVALID-SPI Notification

[Matthew Grooms]

On 1/31/2012 10:42 AM, Sébastien HELLE wrote:
> Hi,
>
> I am currently using ShrewSoft VPN Client to connect to a Fortigate VPN.
> The VPN is route-based, with Mutual RSA authentication.
>
> Every body using this VPN with shrewsoft client is often disconnected,
> either partially (the client is still connected, but some routes are
> unreachable) or totally (the client is disconnected).
>
> When I take a look at the client debug Trace utility (decode mode), I
> have this :
>
> 12/01/31 17:09:47 DB : phase1 found
> 12/01/31 17:09:47 DB : phase1 ref increment ( ref count = 4, obj count = 1 )
> 12/01/31 17:09:47 ii : processing informational packet ( 76 bytes )
> 12/01/31 17:09:47 == : new informational iv ( 16 bytes )
> 12/01/31 17:09:47 0x : 310ab985 d070eb7b b6855596 a6e634d8
> 12/01/31 17:09:47 =< : cookies 3cada944dd48eeba:13485b109cc7cffd
> 12/01/31 17:09:47 =< : message 4991d5d5
> 12/01/31 17:09:47 =< : decrypt iv ( 16 bytes )
> 12/01/31 17:09:47 0x : 310ab985 d070eb7b b6855596 a6e634d8
> 12/01/31 17:09:47 == : decrypt packet ( 76 bytes )
> 12/01/31 17:09:47 0x : 3cada944 dd48eeba 13485b10 9cc7cffd 08100501
> 4991d5d5 0000004c 0b000018
> 12/01/31 17:09:47 0x : afcb164b 10c9e5d6 b49f1177 d368dc15 a84dee09
> 00000010 00000001 0304000b
> 12/01/31 17:09:47 0x : 5d004625 bec85867 fb6ada07
> 12/01/31 17:09:47 <= : trimmed packet padding ( 8 bytes )
> 12/01/31 17:09:47 <= : stored iv ( 16 bytes )
> 12/01/31 17:09:47 0x : 7d379dfc 17b5a654 653d3ded 16a861fe
> 12/01/31 17:09:47 << : hash payload
> 12/01/31 17:09:47 << : notification payload
> 12/01/31 17:09:47 == : informational hash_i ( computed ) ( 20 bytes )
> 12/01/31 17:09:47 0x : afcb164b 10c9e5d6 b49f1177 d368dc15 a84dee09
> 12/01/31 17:09:47 == : informational hash_c ( received ) ( 20 bytes )
> 12/01/31 17:09:47 0x : afcb164b 10c9e5d6 b49f1177 d368dc15 a84dee09
> 12/01/31 17:09:47 ii : informational hash verified
> 12/01/31 17:09:47 ii : received peer INVALID-SPI notification
> 12/01/31 17:09:47 ii : - 217.119.132.38:4500
> <http://217.119.132.38:4500> -> 192.168.30.103:4500
> <http://192.168.30.103:4500>
> 12/01/31 17:09:47 ii : - ipsec-esp spi = 0x5d004625
> 12/01/31 17:09:47 ii : - data size 0
> 12/01/31 17:09:47 DB : phase1 ref decrement ( ref count = 3, obj count = 1 )
> 12/01/31 17:09:50 <- : recv NAT-T:IKE packet 217.119.132.38:4500
> <http://217.119.132.38:4500> -> 192.168.30.103:4500
> <http://192.168.30.103:4500> ( 76 bytes )
> 12/01/31 17:09:50 0x : 3cada944 dd48eeba 13485b10 9cc7cffd 08100501
> afdd4e70 0000004c 4295f33a
> 12/01/31 17:09:50 0x : 1aeba2a3 8399c33e 5393a32f 26f4b98f 96eee83d
> 3738e253 00269a9f b2f4bf2f
> 12/01/31 17:09:50 0x : 70e8b563 ce6bb2aa 848a0774
>
> The important part is the INVALID-SPI Notification from the peer. It
> looks like Shrew client receive the info, but don't care of. I've seen
> that the Cisco VPN Client has a functionnality invalid-spi-recovery. Is
> there nothing like that in Shrew ?
>

After reading the RFC, an INVALID-SPI notification should only be sent 
in response to a IKE level message that includes an SPI that is thought 
to be invalid ( ie. received in a proposal or a notification payload ) ...

http://www.faqs.org/rfcs/rfc2408.html

What is happening right before this section in the error log, and what 
does the Fortigate log detail say regarding the sent notification? Any 
reason? Does it think the SA related to the SPI has expired? Do you have 
a lifetime mismatch between your gateway / client configuration?

-Matthew