Todd M. Simons <tsimons <at> delphi-tech.com>
2006-12-13 01:13:59 GMT
<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.com [mailto:vpn-bounces+tsimons=delphi-tech.com <at> 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
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. ##
RSS Feed