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
_______________________________________________
vpn-help mailing list
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help
