Pix 501 and 3000 Concentrator with IPsec problem

Unanswered Question
Oct 1st, 2009

Hello,

For some reason my Pix 501 and 3000 VPN concentrator are not wanting to play nicely together.

I have setup the pix per this document:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00800949d2.shtml

Except I dont have the overlapping networks. Those I have changed to internal addresses. Here is my config (removed some to make it shorter, if not defined its default):

PIX Version 6.3(5)

interface ethernet0 100full

interface ethernet1 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

hostname PIX-501

domain-name baseline-vps.local

names

access-list inside_pub permit ip 172.30.12.0 255.255.255.0 172.30.15.0 255.255.255.0

access-list crypto1 permit ip 172.30.12.0 255.255.255.0 172.30.15.0 255.255.255.0

ip address outside 172.30.1.10 255.255.255.0

ip address inside 172.30.12.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list inside_pub

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

route outside 0.0.0.0 0.0.0.0 172.30.1.20 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout sip-disconnect 0:02:00 sip-invite 0:03:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server TACACS+ max-failed-attempts 3

aaa-server TACACS+ deadtime 10

aaa-server RADIUS protocol radius

aaa-server RADIUS max-failed-attempts 3

aaa-server RADIUS deadtime 10

aaa-server LOCAL protocol local

floodguard enable

sysopt connection permit-ipsec

crypto ipsec transform-set crypto1transet esp-aes-256 esp-sha-hmac

crypto map crypto1map 10 ipsec-isakmp

crypto map crypto1map 10 match address crypto1

crypto map crypto1map 10 set peer 172.30.1.20

crypto map crypto1map 10 set transform-set crypto1transet

crypto map crypto1map interface outside

isakmp enable outside

isakmp key ******** address 172.30.1.20 netmask 255.255.255.255

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption aes-256

isakmp policy 10 hash sha

isakmp policy 10 group 5

isakmp policy 10 lifetime 86400

telnet timeout 5

ssh timeout 5

console timeout 0

terminal width 80

I setup the 3000 concentrator exactly like it says in the document. However I see NO traffic being sent to construct a tunnel on the PIX (debug cry ips). However if I change the "Routing" setting in the LAN-to-LAN setup on the 3000 (change it to "Network AutoDiscovery") then I start seeing an attempt to establish the tunnel, but it fails with these errors:

ISAKMP: transform 1, ESP_AES

ISAKMP: attributes in transform:

ISAKMP: SA life type in seconds

ISAKMP: SA life duration (basic) of 28800

ISAKMP: encaps is 1

ISAKMP: authenticator is HMAC-SHA

ISAKMP: key length is 256

ISAKMP (0): atts are acceptable.IPSEC(validate_proposal_request):

IPSEC(validate_transform_proposal): proxy identities not supported

IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) dest= 172.30.1.10, src= 172.30.1.20,

dest_proxy= 172.30.1.20/255.255.255.255/0/0 (type=1),

src_proxy= 172.30.1.10/255.255.255.255/0/0 (type=1),

protocol= ESP, transform= esp-aes-256 esp-sha-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x4

IPSEC(validate_transform_proposal): proxy identities not supported

ISAKMP: IPSec policy invalidated proposal

ISAKMP (0): SA not acceptable!

On the Concentrator it fails complaining about an QM FMS error. I have tracked down that these errors are usually complaining about a problem with the ACL's.

I realize the ACL's arent set up properly since its configured in Network AutoDiscovery mode. But If I try to set it up properly then the 3000 stops trying to establish a tunnel all together.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Yudong Wu Thu, 10/01/2009 - 23:08

Yes, from debug, it looks like your ACL on VPN3K was not setup correctly.

On PIX, you have the following ACL for VPN traffic:

ccess-list crypto1 permit ip 172.30.12.0 255.255.255.0 172.30.15.0 255.255.255.0

Therefore, on VPN3K, in step 4 of the link you mentioned, you should configure:

local network as 172.30.15.0/0.0.0.255

remote network as 172.30.12.0/0.0.0.255

efreuchtel Fri, 10/02/2009 - 05:25

Hello,

Thank you for your response kwu2!

I have done that. However when I change the Routing drop down menu to "None" then the VPN3k wont even try to establish a tunnel. I get no attempts and with "debug cry ips", "debug cry isa", and "debug cry engine" I get no messages at all.

If I change the routing drop down to "Network Autodiscovery" then it tries to connect, but the ACL's are wrong so it fails with the previous error messages.

Yudong Wu Fri, 10/02/2009 - 16:33

check the routing table on your VPN3K, if you don't want to use "network autodiscovery", you should add a static route for the remote network 172.30.15.0/24.

LAN-2-LAN VPN will come up when there is related traffic which need to go through tunnel. So VPN3k must have the routing for the remote network in order to bring up the tunnel.

HTH

Patrick0711 Fri, 10/02/2009 - 15:25

The concentrator is sending the following proxy ID proposals:

dest_proxy= 172.30.1.20/255.255.255.255/0/0 (type=1),

src_proxy= 172.30.1.10/255.255.255.255/0/0 (type=1),

Your PIX crypto access-list specifies 172.30.12.0/24 and 172.30.15.0/24, hence the:

IPSEC(validate_transform_proposal): proxy identities not supported

Ensure that the encryption domains match on both devices.

efreuchtel Mon, 10/05/2009 - 05:30

Thanks again patrick and kwu2!

kwu2:

Well I have set up a static route on the VPN 3k sending all traffic going to 172.30.12.0/24 to the outside address of the PIX (172.30.1.10). Is that sufficient?

Patrick0711:

That makes sense however those errors only come up when I try to use the network auto-discovery. I am trying to set this up without using that. Using normal "Use IP Address with Wildcard-mask" it just simply wont connect the tunnel. Neither seem to try to initiate the tunnel at all.

Yudong Wu Mon, 10/05/2009 - 07:29

172.30.1.10 is not a directly connected network. Therefore, VPN3K will need another entry to tell it how to reach 172.30.1.10 unless you have a default route to take care of it.

My suggestion is to add an entry to route 172.30.12.0/24 to the default gateway IP of VPN3K public interface.

efreuchtel Mon, 10/05/2009 - 08:14

Currently 172.30.1.10 is the default route on the VPN3k.

This is a very simple set up. I have a VPN3k and pix sitting on a switch. The default routes are each other. They are literally sitting next to each other for the purpose of this test.

Yudong Wu Mon, 10/05/2009 - 08:32

Sorry, I did not realize that VPN3K public interface and PIX outside are in the same subnet.

So after adding that route in VPN3K and changing remote/local network per previous post, VPN should works.

efreuchtel Mon, 10/05/2009 - 10:57

Yup, Thats why I have been having a hard time figuring this out. I have followed the guides to the letter and it just simply doesnt do anything.

Yudong Wu Mon, 10/05/2009 - 11:01

hmm, that's strange. It should be a straight forward setup.

By the way, when you did the testing, did you initiate any traffic which will match the ACL?

access-list crypto1 permit ip 172.30.12.0 255.255.255.0 172.30.15.0 255.255.255.0.

You can try to initiate traffic from PIX side, so that you can have debug output to see why it does not work.

efreuchtel Mon, 10/05/2009 - 12:59

Well. That was it. I pinged the other side of the bridge and they negotiated the VPN.

Thanks guys, its always the simple stuff that gets me. =\

Actions

This Discussion