10-01-2009 09:20 AM - edited 02-21-2020 04:20 PM
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:
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.
10-01-2009 11:08 PM
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
10-02-2009 05:25 AM
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.
10-02-2009 04:33 PM
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
10-02-2009 03:25 PM
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.
10-05-2009 05:30 AM
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.
10-05-2009 07:29 AM
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.
10-05-2009 08:14 AM
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.
10-05-2009 08:32 AM
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.
10-05-2009 10:57 AM
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.
10-05-2009 11:01 AM
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.
10-05-2009 12:59 PM
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. =\
10-05-2009 01:30 PM
glad that it finally works. :)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: