Re: Cisco Router IOS to Symantec Raptor
"Todd M. Simons" <[email protected]> Tue, 12 Dec 2006 20:13:59 -0500
| Newsgroups | gmane.comp.security.vpn |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1997750505== 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 <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: 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: [email protected] > [mailto:[email protected]] 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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"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=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><I'm a Symantec = person></FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">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)</FONT></P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"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. I have seen Cisco choke = with multiple entities on the Symantec side as well.</FONT></P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Check out:</FONT> <BR> <A = HREF=3D"http://groups.yahoo.com/symantecfirewalls"><U></U><U><FONT = COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">http://groups.yahoo.com/symantecfirewalls</FONT></U></A> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It has some good = content, unfortunately it doesn't have all the old firetower (aka = [rapt]) content. You can try googling: <B> [rapt] +cisco = +vpn</B></FONT></P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">~Todd</FONT> </P> <P><FONT SIZE=3D1 = FACE=3D"Tahoma">_____________________________________________ </FONT> <BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: </FONT></B> <FONT = SIZE=3D1 = FACE=3D"Tahoma">[email protected] = [</FONT><A = HREF=3D"mailto:[email protected]"><U>= <FONT COLOR=3D"#0000FF" SIZE=3D1 = FACE=3D"Tahoma">mailto:[email protected].= com</FONT></U></A><FONT SIZE=3D1 = FACE=3D"Tahoma">] </FONT><B></B><B> <FONT SIZE=3D1 = FACE=3D"Tahoma">On Behalf Of</FONT></B> <FONT SIZE=3D1 = FACE=3D"Tahoma">Nate Goddard</FONT></P> <P><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent: </FONT></B> <FONT = SIZE=3D1 FACE=3D"Tahoma">Tuesday, December 12, 2006 5:58 PM</FONT> <BR><B><FONT SIZE=3D1 = FACE=3D"Tahoma">To: </FONT></B> <FONT SIZE=3D1 = FACE=3D"Tahoma">VPN Lists Schmoo</FONT> <BR><B><FONT SIZE=3D1 = FACE=3D"Tahoma">Subject: </FONT>= </B> <FONT SIZE=3D1 FACE=3D"Tahoma">[VPN] Cisco Router IOS to Symantec = Raptor</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT> <BR> <FONT SIZE=3D2 = 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.</FONT></P> <P> <FONT SIZE=3D2 = FACE=3D"Arial">To lay out some details (which have been obfuscated to = protect identity and security):</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">Cisco side:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Inside IP: 10.1.1.25 (local subnet has = routing to encr dom)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Outside IP: 1.2.3.4</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Preshared key</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">P1: 3DES MD5 DH2</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">P2: 3DES MD5 no-pfs</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Local encryption domain: 7.8.9.0/24 = (public space)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Sample ACL for crypto map:</FONT> <BR> <FONT SIZE=3D2 = FACE=3D"Arial">permit ip 7.8.9.0 0.0.0.255 host 172.16.10.56</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">permit ip 7.8.9.0 0.0.0.255 host = 172.16.10.113</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">permit ip 7.8.9.0 0.0.0.255 host = 172.16.10.78</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">Symantec Raptor side:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Inside IP: 172.16.10.254</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Outside IP: 21.22.23.24</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Preshared key</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">P1: 3DES MD5 DH2</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">P2: 3DES MD5 no-pfs</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Local encryption domain: group = containing 172.16.10.56, 172.16.10.113, 172.16.10.78</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Remote encryption domain: 7.8.9.0 = 255.255.255.0</FONT> </P> <BR> <P> <FONT SIZE=3D2 = 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).</FONT></P> <P> <FONT SIZE=3D2 = 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.</FONT></P> <P> <FONT SIZE=3D2 = 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).</FONT></P> <BR> <P> <FONT SIZE=3D2 = 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?</FONT></P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">Nate</FONT> <BR> <BR><FONT SIZE=3D2 FACE=3D"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> << File: ATT3985625.txt >></FONT>=20 </P> <br>## Scanned by Delphi Technology, Inc. ##</BODY> </HTML> ------_=_NextPart_001_01C71E53.F7D712B3-- --===============1997750505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ VPN mailing list [email protected] http://lists.shmoo.com/mailman/listinfo/vpn --===============1997750505==--