This is a multi-part message in MIME format.

--===============0960009034==
Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C71E53.F7D712B3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71E53.F7D712B3
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



The negotiation a problem with PIX v5.2 thru v6.3, I'm not sure how that
maps to router IOS versions. 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)

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. I have seen
Cisco choke with multiple entities on the Symantec side as well.

Check out:
http://groups.yahoo.com/symantecfirewalls

It has some good content, unfortunately it doesn't have all the old
firetower (aka [rapt]) content. You can try googling: [rapt] +cisco
+vpn

~Todd

> _____________________________________________=20
> From: vpn-bounces+tsimons=3Ddelphi-tech.com@lists.shmoo.com
> [mailto:vpn-bounces+tsimons=3Ddelphi-tech.com@lists.shmoo.com] On
> Behalf Of Nate Goddard
> Sent: Tuesday, December 12, 2006 5:58 PM
> To: VPN Lists Schmoo
> Subject: [VPN] Cisco Router IOS to Symantec Raptor
>=20
> Hello,
> I have been unable to reach the list site to look for any
> archives on this question, so I'll through it out there. I'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. Unfortunately, I can't really provide much
> detail about the Symantec because it's a customer/vendor's device. 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.
> To lay out some details (which have been obfuscated to protect
> identity and security):
>=20
> Cisco side:
> Inside IP: 10.1.1.25 (local subnet has routing to encr dom)
> Outside IP: 1.2.3.4
> Preshared key
> P1: 3DES MD5 DH2
> P2: 3DES MD5 no-pfs
> Local encryption domain: 7.8.9.0/24 (public space)
> Sample ACL for crypto map:
> permit ip 7.8.9.0 0.0.0.255 host 172.16.10.56
> permit ip 7.8.9.0 0.0.0.255 host 172.16.10.113
> permit ip 7.8.9.0 0.0.0.255 host 172.16.10.78
>=20
>=20
> Symantec Raptor side:
> Inside IP: 172.16.10.254
> Outside IP: 21.22.23.24
> Preshared key
> P1: 3DES MD5 DH2
> P2: 3DES MD5 no-pfs
> Local encryption domain: group containing 172.16.10.56, 172.16.10.113,
> 172.16.10.78
> Remote encryption domain: 7.8.9.0 255.255.255.0
>=20
>=20
> 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.
> 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. 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).
> 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. As I said, perhaps deleting the old one
> (not just disabling it) is necessary.
> 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'm ignoring here).
>=20
>=20
> 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?
>=20
>=20
> Nate
>=20
> --=20
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.16/582 - Release Date:
> 12/11/2006 4:32 PM
> << File: ATT3985625.txt >>=20

=0A=
## Scanned by Delphi Technology, Inc. ##
------_=_NextPart_001_01C71E53.F7D712B3
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




charset=3Dus-ascii">
6.5.7650.8">
RE: [VPN] Cisco Router IOS to Symantec Raptor




<I'm a Symantec =
person>



The negotiation a =
problem with PIX v5.2 thru v6.3, I'm not sure how that maps to router =
IOS versions.  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)



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.  I have seen Cisco choke =
with multiple entities on the Symantec side as well.



Check out:


        HREF=3D"http://groups.yahoo.com/symantecfirewalls"> COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://groups.yahoo.com/symantecfirewalls



It has some good =
content, unfortunately it doesn't have all the old firetower (aka =
[rapt]) content.  You can try googling:  [rapt] +cisco =
+vpn



~Todd



FACE=3D"Tahoma">_____________________________________________


From:   SIZE=3D1 =
FACE=3D"Tahoma">vpn-bounces+tsimons=3Ddelphi-tech.com@lists.shmoo.com =
[
HREF=3D"mailto:vpn-bounces+tsimons=3Ddelphi-tech.com@lists.shmoo.com">=
FACE=3D"Tahoma">mailto:vpn-bounces+tsimons=3Ddelphi-tech.com@lists.shmoo.=
com
FACE=3D"Tahoma">]  FACE=3D"Tahoma">On Behalf Of FACE=3D"Tahoma">Nate Goddard



Sent:   SIZE=3D1 FACE=3D"Tahoma">Tuesday, December 12, 2006 5:58 PM


FACE=3D"Tahoma">To:     FACE=3D"Tahoma">VPN Lists Schmoo


FACE=3D"Tahoma">Subject:       =
[VPN] Cisco Router IOS to Symantec =
Raptor



Hello,


        FACE=3D"Arial">I have been unable to reach the list site to look for any =
archives on this question, so I’ll through it out there.  =
I’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.  Unfortunately, I can’t =
really provide much detail about the Symantec because it’s a =
customer/vendor’s device.  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.



        FACE=3D"Arial">To lay out some details (which have been obfuscated to =
protect identity and security):



Cisco side:


Inside IP: 10.1.1.25 (local subnet has =
routing to encr dom)



Outside IP: 1.2.3.4


Preshared key


P1: 3DES MD5 DH2


P2: 3DES MD5 no-pfs


Local encryption domain: 7.8.9.0/24 =
(public space)



Sample ACL for crypto map:


        FACE=3D"Arial">permit ip 7.8.9.0 0.0.0.255 host 172.16.10.56


permit ip 7.8.9.0 0.0.0.255 host =
172.16.10.113



permit ip 7.8.9.0 0.0.0.255 host =
172.16.10.78





Symantec Raptor side:


Inside IP: 172.16.10.254


Outside IP: 21.22.23.24


Preshared key


P1: 3DES MD5 DH2


P2: 3DES MD5 no-pfs


Local encryption domain: group =
containing 172.16.10.56, 172.16.10.113, 172.16.10.78



Remote encryption domain: 7.8.9.0 =
255.255.255.0





        FACE=3D"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.  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.  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).



        FACE=3D"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.  As I said, perhaps deleting the old one =
(not just disabling it) is necessary.



        FACE=3D"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’m ignoring here).





        FACE=3D"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?





Nate




--

No virus found in this outgoing message.

Checked by AVG Free Edition.

Version: 7.5.432 / Virus Database: 268.15.16/582 - Release Date: =
12/11/2006 4:32 PM

  << File: ATT3985625.txt >>
=20




## Scanned by Delphi Technology, Inc. ##

------_=_NextPart_001_01C71E53.F7D712B3--

--===============0960009034==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
VPN mailing list
VPN@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn
--===============0960009034==--