11-30-2007 04:36 AM - edited 02-21-2020 03:24 PM
Hi there,
I'm having a problem with a VPN from a Pix 6.3 to a Cisco 6500. We have several VPNs already configured the same way terminating on the 6500 which work fine. One in particular is virtually identical and is working from another Pix (though this is version 7) to the 6500, with exactly the same access lists identifying traffic to be encrypted. The Pix that now currently has the problem was working fine a week ago and nothing has changed in the configuration on either this or the 6500. It doesn't make sense to me. I've rebooted the Pix several times and I've also rebooted the 6500 but still to no avail. The problem is this, the Pix has on its inside interface the network 10.162.32.0/24. All traffic from this to the 10.0.0.0/8 and the 172.19.229.0/24 networks should be put into the tunnel. What is now happening is that the Pix is putting everything for the 10.0.0.0/8 network into the tunnel but ignoring the traffic for the 172.19.229.0/24 network. Here is output of a 'show crypto ipsec sa' from the Pix for that network. Notice that the traffic for the 172 network gives the error message '#pkts no sa (send) 90'which increments every time a packet is sent, no traffic for it is put into the tunnel:
local ident (addr/mask/prot/port): (10.162.32.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.19.229.0/255.255.255.0/0/0)
current_peer: 10.211.18.250:0
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 decompress failed: 0
#pkts no sa (send) 90, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 10.40.162.249, remote crypto endpt.: 10.211.18.250
path mtu 1500, ipsec overhead 0, 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:
It looks like it just refuses to form an IPSec SA for the 172.19.229.0/24 network. Here are the relevant parts of the configs for the Pix then the 6500. Like I say it used to work a week ago, nothing has changed that I can see (and I've been through the configurations with a fine tooth comb:
Pix
access-list nonat permit ip 10.162.32.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list nonat permit ip 10.162.32.0 255.255.255.0 172.19.229.0 255.255.255.0
access-list traffic_out permit ip 10.162.32.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list traffic_out permit ip 10.162.32.0 255.255.255.0 172.19.229.0 255.255.255.0
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 10.162.32.0 255.255.255.0 0 0
6500
crypto map Metronet 68 ipsec-isakmp
description Access to RemotePix2
set peer 10.40.162.249
set transform-set Strong Medium Weak data_only
match address RemotePix2_Access
crypto map Metronet 70 ipsec-isakmp
ip access-list extended RemotePix2_Access
permit ip 10.0.0.0 0.255.255.255 10.162.32.0 0.0.0.255
permit ip 172.19.229.0 0.0.0.255 10.162.32.0 0.0.0.255
Please can anybody help? I don't think I've overlooked anything and I've had someone else check the configs too and they can't see why it would refuse to put the 172 network into the tunnel.
Thanks
Pete.
11-30-2007 07:29 AM
Pete,
Can you post the ike and ipsec configs from both ends?
It looks like the tunnel is failling to establish, usually a config mismatch at one end.
#pkts no sa (send) 90 means there is no valid security association. This is confirmed as the sas below that are unpopulated.
Have the devices at both ends been re-booted since the problem started? If the sa's get out of order the tunnel will keep trying to re-establish but will not be able to until the crypto engine has been cleared.
Andy.
11-30-2007 07:57 AM
Andy the IKE tunnel is up and all traffic destined for the 10.0.0.0 network is getting put into it. It just won't put traffic for the 172.19.229.0 netowrk into the tunnel. Here's the crypto and ike statements. I know it would suggest an access list mismatch but as you can see that's not the case. Yes both devices have been rebooted and the IKE and IPSec associations cleared several times too.
Pix
access-list nonat permit ip 10.162.32.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list nonat permit ip 10.162.32.0 255.255.255.0 172.19.229.0 255.255.255.0
access-list traffic_out permit ip 10.162.32.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list traffic_out permit ip 10.162.32.0 255.255.255.0 172.19.229.0 255.255.255.0
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 10.162.32.0 255.255.255.0 0 0
crypto ipsec transform-set Strong esp-des esp-md5-hmac
crypto ipsec transform-set Medium esp-des esp-md5-hmac
crypto ipsec transform-set Weak esp-null esp-md5-hmac
crypto ipsec transform-set Data_only esp-des
crypto map MyMap 5 ipsec-isakmp
crypto map MyMap 5 match address traffic_out
crypto map MyMap 5 set peer 10.211.18.250
crypto map MyMap 5 set transform-set Medium
crypto map MyMap interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 1
isakmp policy 1 lifetime 86400
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
6500
crypto map Metronet 68 ipsec-isakmp
description Access to RemotePix2
set peer 10.40.162.249
set transform-set Strong Medium Weak data_only
match address RemotePix2_Access
crypto map Metronet 70 ipsec-isakmp
ip access-list extended RemotePix2_Access
permit ip 10.0.0.0 0.255.255.255 10.162.32.0 0.0.0.255
permit ip 172.19.229.0 0.0.0.255 10.162.32.0 0.0.0.255
Thanks
Pete.
12-03-2007 02:25 AM
Pete,
Can you issue debug crypto isa, then try pinging 172 to 10.
Then u all and debug crypto ipsec and ping again.
Capture the output from that and post (sanitised) and that may have some clues.
Andy.
12-06-2007 03:53 AM
Hi Andy,
it is now sorted out. The problem was that somebody had altered the configuration of the 6500 a couple of weeks ago when they added a new VPN site and accidentally put in an access list for the new site which was incorrect and contained the 172 network. The problem didn't show up immediately because that network is only used occasionally. Thanks for the input. Pete.
12-07-2007 09:58 AM
Pete,
Glad to hear it. Always a problem when more than 1 person is in control of the configs.
Andy.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide