IPSec on Pix 501 with Peering to 3005

Unanswered Question
Feb 18th, 2003
User Badges:

I am working on a net that has about 25 remote locations terminating with a lan to lan Ipsec tunnel, the Corp office has the 3005 with a T1 and remote branch offices have Pix 501 with a basic ipsec config only one peer which is hte 3005, when I come in , in the morning and log into the web admin interface of the 3005 and look at Lan to Lan sessions I usally only see around 6 or 7 and have to ping the others to get them to come up. Sometimes pinging the other side does not bring up the sa for that given peer and sometimes it does, I was wondering 1 if their is a way to log into the remote pix after I have ssh enabled and from the pix try to get the peer to establish instead of having to call users up at the remote locations. Also I am looking at the following command which is suppose to increase the time the SA stays up before renegotiatiing I have never had to use this in the past but was going to apply it to the remote crypto maps to see if it helps has anyone else had to use it ?

crypto map mymap 10 set security-association lifetime seconds 40000

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
ajagadee Tue, 02/18/2003 - 18:49
User Badges:
  • Cisco Employee,


How are the Pix 501's getting their outside ip address, is it static or via DHCP.

If the Pix 501 has a static ip address, then you will be able to initiate traffic from the VPN3000 and if it is via DHCP, then the pix has to be initiator.

There is no way on the pix, that you can generate ipsec traffic once you are SSHed or telnetted into it.

If the configs and IP Connectivity is good, then your tunnel should come up fine once there is interesting traffic flowing through.



andy.g.mrozek Thu, 02/20/2003 - 18:22
User Badges:

It is Static , the outside public interface of the 3005 and the outside interface of the pix 501's are always available thats what I dont understand, I have been monitoring the outside interfaces to see if they bounce up or down and yet they havent, I could understand if they were but their not. The issue is that when I look on the concentrator and look at the lan to lan sessions their may only be 10 or so lan to lan sessions up at a given time, I first check it the remote side's IPSEC peer is up which is the outside interface of the pix and it always is, then I ping the remote side LAN subnet which is defined as the interesting traffic and it doesnt come up, then I call someone up from the other side and have them ping over to me and it doesnt come up, so sometimes it does and sometimes it doesnt and we have to reboot the remote pix. If their is not a statement on the remote PIX for allowing ICMP in, when the tunnel is up and running should I be able to ping the remote side through the tunnel ?

ajagadee Thu, 02/20/2003 - 18:55
User Badges:
  • Cisco Employee,


Interesting. If both the Pix and VPN3000 have static ip addresses, then you should be able to generate traffic from both the sides. Next time when this issue happens, Couple of things that you can do:

1. Clear the ipsec SA's on the pix, "clear crypto ipsec sa" and generate the traffic from behind the VPN3000, if the tunnel does not come up, then generate traffic from behind the Pix.

2. If you are permitting IP in your access-list for the IPSec traffic, then you do not need an explicit ICMP access-list.

3. I would run debugs on the pix:

Debug crypto isakmp

Debug crypto ipsec

and enable Isakmp and IPsec logging on the VPN3000 to see why the tunnels are not coming up.

And also check for any overlapping networks on the VPN3000 for the remote sites.

Rebooting the pix to bring up the tunnel should not be an option for you and is not a viable solution.



andy.g.mrozek Tue, 02/25/2003 - 09:43
User Badges:

That's what I was thinking Arul that possibley their is an overlapping address space that is causing some issues here, the corporate site where the 3005 concentrator is at does not have a router behind it, so all the internal users point to a novell border manager packet filter box for their dfg, then their are static routes in the border manager router that point to the remote site private address space and its gateway points to the internal interface of the vpn gateway and all address space is class a 10.x.x.x /24 something at the corp and remote's. After working on an issue with users who were dialing up with software vpn clients on laptops and terminating on the 3005, that were being given a 10.x.x.x /24 something from the 3005, both phase 1 and phase 2 were completing but they could not connect to internal servers behind the 3005 concentrator, so I changed the address space to a 192.168.x.x /24 something and now all the dial ups are working so I am thinking that the Lan to Lan tunnels may be having the same issue. I have set up many vpns in different combinations and have not seen the issue where the tunnels would come up intermittantly, like I said before one morning you can come into the office sit down and look and their will be 7 sesssions active for lan to lan on the 3005 then when you ping a remote site that is not up and should be up sometimes it comes up and sometimes it doesn't..... who knows


This Discussion