08-02-2008 02:26 PM - edited 02-21-2020 03:52 PM
I'm hoping that someone can help me. I've configured my IX the info the vendor gave us, but the tunnel never comes up. Here's what I got:
our endpoint is: 66.179.80.108
our network is: 192.168.50.0 (255.255.255.0)
Clinic will need to make ACL from 172.24.144.3 to host 192.168.50.83 and 192.168.50.86
Clinic will need to NAT interesting traffic to 172.24.144.0 255.255.255.0
Phase 1
Authentication: Pre-Shared
Encryption: 3DES
Hash: SHA
DH: 1
Lifetime: 86400 sec
Pre-shared Key: <key deleted for obvious reasons>
Phase2
ESP encryption 3DES
ESP authentication
Lifetime 28800
Here's my router config:
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list inbound permit tcp any interface outside eq https
access-list inside_outbound_nat0_acl permit ip 192.168.0.0 255.255.255.0 172.24.144.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip 172.24.144.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list outside_cryptomap_20 permit ip 192.168.0.0 255.255.255.0 172.24.144.0 255.255.255.0
access-list 101 permit ip 192.168.0.0 255.255.255.0 172.24.144.0 255.255.255.0
access-list NoNAT permit ip 192.168.0.0 255.255.255.0 172.24.144.0 255.255.255.0
.ip address outside 75.144.149.131 255.255.255.252
ip address inside 192.168.0.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location 192.168.0.3 255.255.255.255 inside
pdm location 192.168.0.10 255.255.255.255 inside
pdm location 192.168.0.11 255.255.255.255 inside
pdm location 192.168.0.12 255.255.255.255 inside
pdm location 172.24.144.0 255.255.255.0 outside
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface 4000 192.168.0.3 4000 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 4001 192.168.0.10 4001 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 4002 192.168.0.11 4002 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 4003 192.168.0.12 4003 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface www 192.168.0.3 www netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https 192.168.0.3 https netmask 255.255.255.255 0 0
access-group inbound in interface outside
route outside 0.0.0.0 0.0.0.0 75.144.149.141 1
timeout xlate 0:05: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
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 20 ipsec-isakmp
crypto map outside_map 20 match address outside_cryptomap_20
crypto map outside_map 20 set peer 66.179.80.108
crypto map outside_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
isakmp enable outside
isakmp key ******** address 66.179.80.108 netmask 255.255.255.255
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 1
isakmp policy 20 lifetime 86400
telnet 192.168.0.0 255.255.255.0 inside
management-access inside
dhcpd address 192.168.0.2-192.168.0.254 inside
Hopefully someone can tell me if the configuration is correct or if my config is correctI'm missing someting cal tell me what the problem is with the tunnel on the otehr end. Thanks for any help.
08-02-2008 06:25 PM
Here's what I get from the Debug information when I try to ping a resource on the remote network:
CFMpis# IPSEC(key_engine): request timer fired: count = 2,
(identity) local= 75.144.194.113, remote= 66.179.80.108,
local_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),
remote_proxy= 172.24.144.0/255.255.255.0/0/0 (type=4)
CFMpis#
ISAKMP (0): beginning Main Mode exchange
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
OAK_MM exchange
ISAKMP (0): processing SA payload. message ID = 0
ISAKMP (0): Checking ISAKMP transform 1 against priority 20 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 1
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): processing vendor id payload
ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
return status is IKMP_NO_ERROR
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
OAK_MM exchange
ISAKMP (0): processing KE payload. message ID = 0
ISAKMP (0): processing NONCE payload. message ID = 0
ISAKMP (0): processing vendor id payload
ISAKMP (0): processing vendor id payload
ISAKMP (0): received xauth v6 vendor id
ISAKMP (0): processing vendor id payload
ISAKMP (0): speaking to another IOS box!
ISAKMP (0): processing vendor id payload
ISAKMP (0): speaking to a VPN3000 concentrator
ISAKMP (0): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
ISAKMP (0): Total payload length: 12
return status is IKMP_NO_ERROR
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
OAK_MM exchange
ISAKMP (0): processing ID payload. message ID = 0
ISAKMP (0): processing HASH payload. message ID = 0
ISAKMP (0): processing vendor id payload
ISAKMP (0): remote peer supports dead peer detection
ISAKMP (0): SA has been authenticated
ISAKMP (0): beginning Quick Mode exchange, M-ID of -872681408:cbfbf040IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0xfa170e13(4195814931) for SA
from 66.179.80.108 to 75.144.194.113 for prot 3
return status is IKMP_NO_ERROR
ISAKMP (0): sending INITIAL_CONTACT notify
ISAKMP (0): sending NOTIFY message 24578 protocol 1
VPN Peer: ISAKMP: Added new peer: ip:66.179.80.108/500 Total VPN Peers:1
VPN Peer: ISAKMP: Peer ip:66.179.80.108/500 Ref cnt incremented to:1 Total VPN Peers:1
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 18 protocol 1
spi 0, message ID = 867375804
return status is IKMP_NO_ERR_NO_TRANS
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
ISAKMP (0): processing DELETE payload. message ID = 553406516, spi size = 16
ISAKMP (0): deleting SA: src 75.144.194.113, dst 66.179.80.108
return status is IKMP_NO_ERR_NO_TRANS
ISADB: reaper checking SA 0xaddf7c, conn_id = 0 DELETE IT!
VPN Peer: ISAKMP: Peer ip:66.179.80.108/500 Ref cnt decremented to:0 Total VPN Peers:1
VPN Peer: ISAKMP: Deleted peer: ip:66.179.80.108/500 Total VPN peers:0IPSEC(key_engine): got a queue event...
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
IPSEC(key_engine_delete_sas): delete all SAs shared with 66.179.80.108
08-02-2008 06:28 PM
Kevin
Is this a new install for this PIX or is it an existing machine to which you are adding VPN?
Are other connections and functions working and there is just a problem with VPN or are there problems with other things?
In looking at the config I notice this issue:
the outside interface defines a subnet of .ip address outside 75.144.149.131 255.255.255.252. But the default route of route outside 0.0.0.0 0.0.0.0 75.144.149.141 1 has a next hop address that is not in the subnet of the outside interface. What happens if you make the default route agree with the interface subnet?
HTH
Rick
08-03-2008 07:47 PM
The outside interface is 75.144.149.113 and the default gateway is 75.144.149.114 (which are on the same subnet), I changed the IP addresses to hide the real ones, but since I didn't include the actual pre-shared key, its not that big of a deal. The real config from the router has the correct IP address and gateway information in it and working.
To answer your questions, this is a new PIX. The Internet connection is setup and functional. This office is trying to get this tunnel setup with a vendor so the doctor can submit prescriptions directly over the Internet (through the tunnel). All the port redirects that are setup on the device also function correctly. The only issue is the tunnel. What I'm trying to confirm is that I've setup the parameters for the tunnel correctly according to the information that the company sent me.
--------------------
Here is the information to company gave me:
our endpoint is: 66.179.80.108
our network is: 192.168.50.0 (255.255.255.0)
Clinic will need to make ACL from 172.24.144.3 to host 192.168.50.83 and 192.168.50.86
Clinic will need to NAT interesting traffic to 172.24.144.0 255.255.255.0
Phase 1
Authentication: Pre-Shared
Encryption: 3DES
Hash: SHA
DH: 1
Lifetime: 86400 sec
Pre-shared Key:
Phase2
ESP encryption 3DES
ESP authentication
Lifetime 28800
--------------------
Do I have the ACLs setup correctly for the remote network? I know that the tunnel fires when I try to ping something on the 172.24.144.x network (I see that on the debug screen), but I don't think the tunnel is sucessfully connecting. I just don't know how to read the debug information to know exactly where the connection is failing. I don't know if it's the configuration on my end or some other problem.
I put the debug information in a previous message, but if you want me to post it again, let me know. Also, if you want to see the entire router config, let me know as I had to take a few lines out of the one I posted to get it under 4000 characters. Everything for the VPN tunnel is in there though.
In the debug information, here's where I think it's failing:
ISAKMP (0): SA has been authenticated
ISAKMP (0): beginning Quick Mode exchange, M-ID of -1702920109:9a7f8053IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0x46182c52(1175989330) for SA
from 66.179.80.108 to 75.144.194.113 for prot 3
return status is IKMP_NO_ERROR
ISAKMP (0): sending INITIAL_CONTACT notify
ISAKMP (0): sending NOTIFY message 24578 protocol 1
VPN Peer: ISAKMP: Added new peer: ip:66.179.80.108/500 Total VPN Peers:1
VPN Peer: ISAKMP: Peer ip:66.179.80.108/500 Ref cnt incremented to:1 Total VPN Peers:1
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 18 protocol 1
spi 0, message ID = 3206685028
return status is IKMP_NO_ERR_NO_TRANS
crypto_isakmp_process_block:src:66.179.80.108, dest:75.144.194.113 spt:500 dpt:500
ISAKMP (0): processing DELETE payload. message ID = 1448807007, spi size = 16
ISAKMP (0): deleting SA: src 75.144.194.113, dst 66.179.80.108
return status is IKMP_NO_ERR_NO_TRANS
ISADB: reaper checking SA 0xaddf7c, conn_id = 0 DELETE IT!
VPN Peer: ISAKMP: Peer ip:66.179.80.108/500 Ref cnt decremented to:0 Total VPN Peers:1
VPN Peer: ISAKMP: Deleted peer: ip:66.179.80.108/500 Total VPN peers:0IPSEC(key_engine): got a queue event...
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
IPSEC(key_engine_delete_sas): delete all SAs shared with 66.179.80.108
-------------------------------
The SA get authenticated, but then gets deleted. I'm not versed enough in PIX debug information to know what's going wrong at this point :(
Any help would really be appreciated! Thanks!
08-05-2008 07:23 PM
Can anyone shed some light on the debug information? My email address changed (hence my user name) and is not kcoe@snet.net. If you need to send me a message you can do so at kcoect at gmail.
08-06-2008 12:32 PM
Hi,
you mentioned earlier in your post that your network is 192.168.50.0/24 but why are you using 192.168.0.0/24 address in your crypto and nat 0 acls ?
From debugs :
local_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),
remote_proxy= 172.24.144.0/255.255.255.0/0/0 (type=4)
Match your crypto acls on both sides .they should be mirror image of each other.
Post config of other vpn end also.
HTH
Saju.
08-06-2008 06:37 PM
The local network on my side is 192.168.1.x and the remote network is 172.24.144.x. The 192.168.50.x was a network in the message that I recieved, so I think that may have been for a different company. From what I've gathered from other individuals is that the most likely cause is that I have the pre
shared key wrong. I'm trying to get that verified right now and will post a message if that is what was wrong...
08-07-2008 01:07 PM
Kevin
It will be interesting to see what you find out. Based on the debug posted earlier I do not believe that it is a problem with the pre shared key. In an earlier post there was this in the debug:
ISAKMP (0): SA has been authenticated
ISAKMP (0): beginning Quick Mode exchange, M-ID of -872681408:cbfbf040IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0xfa170e13(4195814931) for SA
from 66.179.80.108 to 75.144.194.113 for prot 3
I do not believe that you would get the SA authenticated and begin Quick Mode if there were problems with the pre shared key.
HTH
Rick
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