LAN-to-LAN IPSec Tunnel between PIX 501 and VPN 3000 Concentrator

[Devildoc007]

Hello,

I really need help on this issue that i am having. Any help is greatly appreciated.

I am trying to create a bi-directional LAN-to-LAN IPSec tunnel between a PIX 501 at a remote office and Cisco VPN 3005 concentrator at the central office.

The two offices are using PIX devices for PAT. Their LAN IP segments are not overlapping. I deployed the concentrator parallel to the PIX with one external interface connected directly to the Internet and the internal interface connected directly to the internal LAN. My VPN concentrator has a release version of 4.1.5.

I found a document (http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00800949d2.shtml) from Cisco's site to do this and followed the same instructions from the document. The only difference between my deployment and the document is that my two offices are connected to the Internet whereas the document has PIX connected directly to the Concentrator via a switch (direct link between PIX and Concentrator).

After I implemented the configurations, nothing happened. No IPSec tunnel. I issued the command "show crypto ipsec sa" on the PIX and noted that the PIX recognized the local and remote ident peers but no packets of any type was seen (zero packets).

Am i missing something from the configuration? Any prerequisite or special requirement for this kind of configuration? Is there an easier way or better way to obtain this kind of goal? Please, any help is greatly appreciated. Thank you.

JD

[pkapoor]

Send me the "sh crypto ipsec sa" output.

[wambari]

Hello,

I have a similar problem though mine is a VPN 3000 to 1760 setup.

Here is the output for both 'sh crypto isakmp sa' and 'sh crypto ipsec sa'

sh crypto isakmp sa

dst src state conn-id slot

10.200.0.26 10.200.0.2 QM_IDLE 32 0

sh crypto ipsec sa

interface: Ethernet1/0

Crypto map tag: to_vpn, local addr. 10.200.0.26

protected vrf:

local ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

current_peer: 10.200.0.2:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.200.0.26, remote crypto endpt.: 10.200.0.2

path mtu 1500, media mtu 1500

current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

[pkapoor]

Your tunnel is not even up.

You need to send some traffic between the 192.168.1.0 and 192.168.3.0 subnets before the router and concentrator will build the tunnel. Try something like a ping that will invoke the tunnel.

[Devildoc007]

Unfortunately, i don't have the output anymore. Due to the urgency of a VPN connectivity for my remote users, i have configured a PIX-to-PIX VPN instead. However, my output for the "sh crypto ipsec sa" looked exactly like the output posted by Wambari.

JD

[pkapoor]

Check my post to wambari.

[micle2]

If your PIX and Concentrator are parallel... and you have your PIX as your LAN default gateway... then that's likely the problem. If your PC needs to get to the remote subnet across the tunnel it will send that packet to your PIX, the PIX would then need to send that packet over to the Concentrator, which then should forward that packet across the tunnel it has with the remote PIX. The issue lies with the 2nd part of that equation because the PIX does not do redirects and thus will not forward the packet to Concentrator (because it figures the PC could have sent that packet directly to the Concentrator).

[Devildoc007]

Thank you for the responses; however, my PIX is not the LAN default gateway. The LAN default gateway is the internal router. And i have tried sending ping packets without any success.

My network setup is that the remote office has only one PIX as the default gateway and no VPN concentrator. The central office has one PIX in front of the central internal router acting as the default gateway for all traffics, and a concentrator with one external interface connected directly to the Internet and one internal interface connected directly to the internal LAN. The central internal router is the default gateway for all PC's, and i have a route on the central router to forward all VPN traffics at the central office to the concentrator. The remote office's PIX would make a VPN tunnel to the concentrator.

I have tried sending ping packets from the remote office to the central office without success. My "sh crypto ipsec sa" still shows no packets.

JD

[micle2]

Does the PIX even show the tunnel being up? If you do a 'show cry isa sa' do you see it QM_IDLE? When you do 'show cry ips sa' do you see 4 different SAs? What about on the Concentrator? Does Administer Session show the tunnel up? What if you ping from that side? Do you see encrypt but no decrypt?

[Devildoc007]

No, neither the PIX nor the concentrator shows the tunnel is up. I think that is our problem that we are trying to resolve here. I am trying to determine why neither tunnel is up.

[pkapoor]

Did you try to send traffic over the tunnel? Because as I said, the tunnel will not come up until such time there is traffic that invokes the tunnel.

Try initiating traffic from either side.

[Devildoc007]

Yes, i did. I tried to send ping packets from both sides with no reply and no tunnel established.

[micle2]

You're doing 'show cry ipsec sa' (Phase 2) before you're even checking to see if Phase 1 is up. You need to see if the PIX even considers your packet as 'interesting' enough to bring up the tunnel. If you try to ping, even though it might fail, you should see activity on the PIX. When you're pinging and you do a 'show crypto isa sa' from the PIX, you should see it doing something. QM_IDLE is where you want to end up at but you might be at some other stage. If you don't even see that then you have configuration issues. Make sure your access-lists match. Do a basic checkup and make sure your crypto map is actually applied to the outside interface.

Things like that. Or else you'll have to run debugs to find out what's going on then.

[pkapoor]

That could be a possible reason why the traffic that you are trying to send over the tunnel is not even making it to the IPSec tunnel's endpoint, which is resulting the tunnel not even being invoked.