[vpn-help] 2.1.5 -> 2.1.6b10 -- Connection silently dies after 5 minutes

[Aaron Sarazan]

Looks like this may have just been a case of needing a firmware upgrade on
the router, upgraded from 3.0.5-25 to 3.0.6-25 and not only has mode-config
started working (a different battle altogether), but the ping stays up, and
DPD shows up as advertised. I'll let you know if I see anything else wonky
(looks like the linux version of 2.1.6b10 is having issues)

Thanks for the help! Sorry I didn't try a firmware upgrade sooner :-(

On Fri, Jul 9, 2010 at 6:50 PM, Matthew Grooms <mgrooms at shrew.net> wrote:

> On 7/8/2010 1:01 PM, Aaron Sarazan wrote:
>
>> Here's a snippet from when I tested it out this morning. I think it died
>> before I actually disconnected from the client side-- although it looks
>> like the gateway did get the disconnect signal and shut down the
>> connection. Doesn't look like there's much of interest from when it
>> actually died.
>>
>> Is it common for a gateway to fail to correctly advertise dead peer
>> detection (or for shrew to possibly misinterpret the advertisement)?
>>
>>
> No, its not. RFC3706 clearly states that a peer MUST provide a vendor ID to
> be compliant with the specification. It's really not possible to
> misinterpret the requirement or the ID value when sent correctly.
>
> http://www.faqs.org/rfcs/rfc3706.html ...
>
> 5.1.  DPD Vendor ID
>
>   To demonstrate DPD capability, an entity must send the DPD vendor ID.
>   Both peers of an IKE session MUST send the DPD vendor ID before DPD
>   exchanges can begin.  The format of the DPD Vendor ID is:
>
>                                     1
>                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                !                           !M!M!
>                !      HASHED_VENDOR_ID     !J!N!
>                !                           !R!R!
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,
>   0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond
>   to the current major and minor version of this protocol (1 and 0
>   respectively).  An IKE peer MUST send the Vendor ID if it wishes to
>   take part in DPD exchanges.
>
> ... I just fired up my FVS338 to run some tests. The tunnel has been up and
> running for over 30 mins now and its still passing traffic fine. The
> negotiation looks almost identical to yours but I'm using a modecfg record.
> I also don't force the NAT-T operation, it just gets negotiated normally,
> detects the NAT and switches to port 4500.
>
> One other thing to check: When you run the ping that eventually stops
> returning traffic, do you see the 'Transferred' values in the Security
> Association Tab constantly increase? This can be seen in the VPN Trace
> application.
>
> -Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20100710/b62fd630/attachment-0001.html>