<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.8">
<TITLE>RE: [VPN] Cisco Router IOS to Symantec Raptor</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">&lt;I'm a Symantec person&gt;</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The negotiation a problem with PIX v5.2 thru v6.3, I'm not sure how that maps to router IOS versions.&nbsp; One way around this is to set the Symantec side timeouts higher than the Cisco side, and have a persistent PING going from a host behind the PIX (yes, I spent way too much time on this)</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">You may also try defining a class C space on the Symantec side, then restrict tunnel access to the 3 specific hosts using either the proxy services with rules or with filters on the VPN policy.&nbsp; I have seen Cisco choke with multiple entities on the Symantec side as well.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Check out:</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://groups.yahoo.com/symantecfirewalls"><U></U><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">http://groups.yahoo.com/symantecfirewalls</FONT></U></A>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">It has some good content, unfortunately it doesn't have all the old firetower (aka [rapt]) content.&nbsp; You can try googling:&nbsp;<B> [rapt] +cisco +vpn</B></FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">~Todd</FONT>
</P>

<P><FONT SIZE=1 FACE="Tahoma">_____________________________________________ </FONT>

<BR><B><FONT SIZE=1 FACE="Tahoma">From: &nbsp;</FONT></B> <FONT SIZE=1 FACE="Tahoma">vpn-bounces+tsimons=delphi-tech.com@lists.shmoo.com [</FONT><A HREF="mailto:vpn-bounces+tsimons=delphi-tech.com@lists.shmoo.com"><U><FONT COLOR="#0000FF" SIZE=1 FACE="Tahoma">mailto:vpn-bounces+tsimons=delphi-tech.com@lists.shmoo.com</FONT></U></A><FONT SIZE=1 FACE="Tahoma">]&nbsp;</FONT><B></B><B> <FONT SIZE=1 FACE="Tahoma">On Behalf Of</FONT></B> <FONT SIZE=1 FACE="Tahoma">Nate Goddard</FONT></P>

<P><B><FONT SIZE=1 FACE="Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Tahoma">Tuesday, December 12, 2006 5:58 PM</FONT>

<BR><B><FONT SIZE=1 FACE="Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Tahoma">VPN Lists Schmoo</FONT>

<BR><B><FONT SIZE=1 FACE="Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Tahoma">[VPN] Cisco Router IOS to Symantec Raptor</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Hello,</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">I have been unable to reach the list site to look for any archives on this question, so I&#8217;ll through it out there.&nbsp; I&#8217;m trying to setup a IPSec VPN tunnel from a Cisco Router (on which I have several hundred successful site-to-site tunnels) running IOS 12.4(7) to a Symantec Raptor.&nbsp; Unfortunately, I can&#8217;t really provide much detail about the Symantec because it&#8217;s a customer/vendor&#8217;s device.&nbsp; At one point the tunnel did work, but started failing, and now it fails when something behind the Symantec tries to initiate a tunnel, but not when something behind the Router initiates the tunnel.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">To lay out some details (which have been obfuscated to protect identity and security):</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Cisco side:</FONT>

<BR><FONT SIZE=2 FACE="Arial">Inside IP: 10.1.1.25 (local subnet has routing to encr dom)</FONT>

<BR><FONT SIZE=2 FACE="Arial">Outside IP: 1.2.3.4</FONT>

<BR><FONT SIZE=2 FACE="Arial">Preshared key</FONT>

<BR><FONT SIZE=2 FACE="Arial">P1: 3DES MD5 DH2</FONT>

<BR><FONT SIZE=2 FACE="Arial">P2: 3DES MD5 no-pfs</FONT>

<BR><FONT SIZE=2 FACE="Arial">Local encryption domain: 7.8.9.0/24 (public space)</FONT>

<BR><FONT SIZE=2 FACE="Arial">Sample ACL for crypto map:</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">permit ip 7.8.9.0 0.0.0.255 host 172.16.10.56</FONT>

<BR><FONT SIZE=2 FACE="Arial">permit ip 7.8.9.0 0.0.0.255 host 172.16.10.113</FONT>

<BR><FONT SIZE=2 FACE="Arial">permit ip 7.8.9.0 0.0.0.255 host 172.16.10.78</FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">Symantec Raptor side:</FONT>

<BR><FONT SIZE=2 FACE="Arial">Inside IP: 172.16.10.254</FONT>

<BR><FONT SIZE=2 FACE="Arial">Outside IP: 21.22.23.24</FONT>

<BR><FONT SIZE=2 FACE="Arial">Preshared key</FONT>

<BR><FONT SIZE=2 FACE="Arial">P1: 3DES MD5 DH2</FONT>

<BR><FONT SIZE=2 FACE="Arial">P2: 3DES MD5 no-pfs</FONT>

<BR><FONT SIZE=2 FACE="Arial">Local encryption domain: group containing 172.16.10.56, 172.16.10.113, 172.16.10.78</FONT>

<BR><FONT SIZE=2 FACE="Arial">Remote encryption domain: 7.8.9.0 255.255.255.0</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">It use to work fine this way, with a single local group for the hosts on the Raptor side, and a subnet on the Cisco side, and each host had its own IPSec SA (tunnel) to the subnet on the Cisco side.&nbsp; Then the Raptor changed behavior and started to try to use any existing SA for any 1 of the 3 hosts to encrypt traffic for the other 2 when a system behind the Raptor was the initiator of traffic and negotiations. If the Cisco side initiates to all 3 separately, creating the SAs itself, then the tunnel works bi-directionally as it should, until the P2 SAs expire.&nbsp; At the moment, there is no way to identify what firmware change, or config change on the Raptor caused this, so rolling things back is not a practical option (unless someone knows exactly what the issue is).</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">We tried disabling that group and tunnel (perhaps deleting it would be more thorough and a better test ?) and creating 3 totally separate tunnels on the Raptor, using the same key, etc as the 1 defined S-2-S tunnel on the Cisco, but system behind the Raptor still can not initiate a tunnel.&nbsp; As I said, perhaps deleting the old one (not just disabling it) is necessary.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">I ran into the same issue with another customer/vendor using a Raptor, where they were using a group, and switching them to individual tunnels resolved the bi-directional initiation issues (it introduced some minor problems that I&#8217;m ignoring here).</FONT></P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">Anyone have any experience with a Cisco to Raptor tunnel with a subnet and hosts (or anything like this) that could shed some light on this?</FONT></P>
<BR>

<P><FONT SIZE=2 FACE="Arial">Nate</FONT>
<BR>

<BR><FONT SIZE=2 FACE="Times New Roman">--<BR>
No virus found in this outgoing message.<BR>
Checked by AVG Free Edition.<BR>
Version: 7.5.432 / Virus Database: 268.15.16/582 - Release Date: 12/11/2006 4:32 PM<BR>
&nbsp; &lt;&lt; File: ATT3985625.txt &gt;&gt;</FONT> 
</P>

<br>## Scanned by Delphi Technology, Inc. ##</BODY>
</HTML>