From ngoddard at nconnect.net Tue Dec 12 17:57:56 2006 From: ngoddard at nconnect.net (Nate Goddard) Date: Tue, 12 Dec 2006 16:57:56 -0600 Subject: [VPN] Cisco Router IOS to Symantec Raptor Message-ID: <011901c71e40$f7104f90$860a3205@powcomp.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5998 bytes Desc: not available Url : http://lists.shmoo.com/pipermail/vpn/attachments/20061212/b6a7f94b/attachment.bin From tsimons at delphi-tech.com Tue Dec 12 20:13:59 2006 From: tsimons at delphi-tech.com (Todd M. Simons) Date: Tue, 12 Dec 2006 20:13:59 -0500 Subject: [VPN] Re: Cisco Router IOS to Symantec Raptor Message-ID: <6BEB7C2F4C712045AA210FC242934F7502BCF96D@NJ-EXCHANGE1.AD.dti> 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. ## -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20061212/395392f0/attachment.htm From prueconsulting at gmail.com Fri Dec 22 11:05:51 2006 From: prueconsulting at gmail.com (Patrick) Date: Fri, 22 Dec 2006 16:05:51 +0000 (UTC) Subject: [VPN] Re: Monitoring non-GRE tunnel VPNs References: <6A85E2ED-891C-46A4-A9EE-15115E5484B8@breathe-underwater.com> Message-ID: Joseph Jenkins breathe-underwater.com> writes: > > > My ideal would solution would be the notification of tunnel A going > up or down, while not getting any notifications on tunnel B. I have > spoke to Cisco and done some searches on the web and have not found > anything that would help. Please if anyone has any ideas I would be > interested to hear them. > > TIA > > Joseph Jenkins > You can use the peer descriptions in the IOS and then monitor your syslog messages for tunnel status I am currently doing this using SEC combined with Syslog-ng and the taking approriate actions based on the output. From tbird at precision-guesswork.com Thu Dec 28 16:55:17 2006 From: tbird at precision-guesswork.com (Tina Bird) Date: Thu, 28 Dec 2006 13:55:17 -0800 Subject: [VPN] List vacation Message-ID: <00d001c72aca$dde12a30$1701a8c0@lindesfarne> Hi all -- I've just returned from my winter holidays, and cleared out huge quantities of spam from the moderation queue. I tried to check everything with a vaguely plausible subject line (using an apparently excessively generous definition of "plausible"), but it's possible that I deleted some legitimate traffic. If you've posted something and it has not been distributed, please re-submit it. thanks -- tbird