VPN
[VPN] Re: Cisco Router IOS to Symantec Raptor Dec 13 2006 01:13AM
Todd M. Simons (tsimons delphi-tech com)
<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

> _____________________________________________
> From: vpn-bounces+tsimons=delphi-tech.com (at) lists.shmoo (dot) com [email concealed]
> [mailto:vpn-bounces+tsimons=delphi-tech.com (at) lists.shmoo (dot) com [email concealed]] 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
>
> 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):
>
> 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
>
>
> 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
>
>
> 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).
>
>
> 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 >>

## Scanned by Delphi Technology, Inc. ##<!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"><I'm a Symantec person></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.  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.  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>        <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.  You can try googling: <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:  </FONT></B> <FONT SIZE=1 FACE="Tahoma">vpn-bounces+tsimons=delphi-tech.com (at) lists.shmoo (dot) com [email concealed] [</FONT><A HREF="mailto:vpn-bounces+tsimons=delphi-tech.com (at) lists.shmoo (dot) com [email concealed]"><U><FO
NT COLOR="#0000FF" SIZE=1 FACE="Tahoma">mailto:vpn-bounces+tsimons=delphi-tech.com (at) lists.shmoo (dot) com [email concealed]
</FONT></U></A><FONT SIZE=1 FACE="Tahoma">] </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:  </FONT></B> <FONT SIZE=1 FACE="Tahoma">Tuesday, December 12, 2006 5:58 PM</FONT>

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

<BR><B><FONT SIZE=1 FACE="Tahoma">Subject:       </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>        <FONT SIZE=2 FACE="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=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>        <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>        <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.  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=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.  As I said, perhaps deleting the old one (not just disabling it) is necessary.</FONT></P>

<P>        <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’m ignoring here).</FONT></P>
<BR>

<P>        <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>
  << File: ATT3985625.txt >></FONT>
</P>

<br>## Scanned by Delphi Technology, Inc. ##</BODY>
</HTML>_______________________________________________
VPN mailing list
VPN (at) lists.shmoo (dot) com [email concealed]
http://lists.shmoo.com/mailman/listinfo/vpn

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus