Pix won't put certain traffic into VPN

Unanswered Question
Nov 30th, 2007

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
andyjames Fri, 11/30/2007 - 07:29

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.

Peter.D.Brown Fri, 11/30/2007 - 07:57

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.

andyjames Mon, 12/03/2007 - 02:25

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.

Peter.D.Brown Thu, 12/06/2007 - 03:53

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.

andyjames Fri, 12/07/2007 - 09:58

Pete,

Glad to hear it. Always a problem when more than 1 person is in control of the configs.

Andy.

Actions

This Discussion