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