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)<div>
<br></div><div>Thanks for the help! Sorry I didn't try a firmware upgrade sooner :-(<br><div><br><div class="gmail_quote">On Fri, Jul 9, 2010 at 6:50 PM, Matthew Grooms <span dir="ltr"><<a href="mailto:mgrooms@shrew.net">mgrooms@shrew.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 7/8/2010 1:01 PM, Aaron Sarazan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here's a snippet from when I tested it out this morning. I think it died<br>
before I actually disconnected from the client side-- although it looks<br>
like the gateway did get the disconnect signal and shut down the<br>
connection. Doesn't look like there's much of interest from when it<br>
actually died.<br>
<br>
Is it common for a gateway to fail to correctly advertise dead peer<br>
detection (or for shrew to possibly misinterpret the advertisement)?<br>
<br>
</blockquote>
<br></div>
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.<br>
<br>
<a href="http://www.faqs.org/rfcs/rfc3706.html" target="_blank">http://www.faqs.org/rfcs/rfc3706.html</a> ...<br>
<br>
5.1.  DPD Vendor ID<br>
<br>
   To demonstrate DPD capability, an entity must send the DPD vendor ID.<br>
   Both peers of an IKE session MUST send the DPD vendor ID before DPD<br>
   exchanges can begin.  The format of the DPD Vendor ID is:<br>
<br>
                                     1<br>
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br>
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
                !                           !M!M!<br>
                !      HASHED_VENDOR_ID     !J!N!<br>
                !                           !R!R!<br>
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
   where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,<br>
   0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond<br>
   to the current major and minor version of this protocol (1 and 0<br>
   respectively).  An IKE peer MUST send the Vendor ID if it wishes to<br>
   take part in DPD exchanges.<br>
<br>
... 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.<br>

<br>
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.<br>
<font color="#888888">
<br>
-Matthew<br>
</font></blockquote></div><br></div></div>