cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
605
Views
0
Helpful
4
Replies

PIX to PIX VPN

chris
Level 1
Level 1

am having trouble getting a PIX to PIX vpn working. It's between a pix-506 firmware 6.1(1) and a pix-506 firmware 5.1(1). This is what I get when I have debug crypto ipsec, and debug crypto isakmp enabled and I try to ping from pixA to pixB:

VPN Peer: ISAKMP: Added new peer: ip:65.114.226.162 Total VPN Peers:1

VPN Peer: ISAKMP: Peer ip:65.114.226.162 Ref cnt incremented to:1 Total VPN Peer

s:1

ISAKMP (0): beginning Main Mode exchange

crypto_isakmp_process_block: src 65.114.226.162, dest 63.230.113.162

OAK_MM exchange

ISAKMP (0): processing SA payload. message ID = 0

ISAKMP (0): Checking ISAKMP transform 1 against priority 1 policy

ISAKMP: encryption DES-CBC

ISAKMP: hash MD5

ISAKMP: default group 1

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (basic) of 1000

ISAKMP (0): atts are acceptable. Next payload is 0

ISAKMP (0): SA is doing pre-shared key authentication using id type ID_FQDN

return status is IKMP_NO_ERROR

crypto_isakmp_process_block: src 65.114.226.162, dest 63.230.113.162

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): speaking to another IOS box!

ISAKMP (0): ID payload

next-payload : 8

type : 2

protocol : 17

port : 500

length : 27

ISAKMP (0): Total payload length: 31

return status is IKMP_NO_ERROR

crypto_isakmp_process_block: src 65.114.226.162, dest 63.230.113.162

OAK_MM exchange

ISAKMP (0): processing ID payload. message ID = 0

ISAKMP (0): processing HASH payload. message ID = 0

ISAKMP (0): SA has been authenticated

ISAKMP (0): beginning Quick Mode exchange, M-ID of -1838113416:92709d78IPSEC(key

_engine): got a queue event...

IPSEC(spi_response): getting spi 0x97b8112(159088914) for SA

from 65.114.226.162 to 63.230.113.162 for prot 3

return status is IKMP_NO_ERROR

crypto_isakmp_process_block: src 65.114.226.162, dest 63.230.113.162

OAK_QM exchange

oakley_process_quick_mode:

OAK_QM_IDLE

ISAKMP (0): processing SA payload. message ID = 2456853880

ISAKMP : Checking IPSec proposal 1

ISAKMP: transform 1, ESP_DES

ISAKMP: attributes in transform:

ISAKMP: encaps is 1

ISAKMP: SA life type in seconds

ISAKMP: SA life duration (basic) of 28800

ISAKMP: SA life type in kilobytes

ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0

ISAKMP: authenticator is HMAC-MD5

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

#1,

(key eng. msg.) dest= 65.114.226.162, src= 63.230.113.162,

dest_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),

src_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-des esp-md5-hmac ,

lifedur= 0s and 0kb,

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

ISAKMP (0): processing NONCE payload. message ID = 2456853880

ISAKMP (0): processing ID payload. message ID = 2456853880

ISAKMP (0): processing ID payload. message ID = 2456853880

ISAKMP (0): Creating IPSec SAs

inbound SA from 65.114.226.162 to 63.230.113.162 (proxy 192.168.1.

0 to 192.168.0.0)

has spi 159088914 and conn_id 4 and flags 4

lifetime of 28800 seconds

lifetime of 4608000 kilobytes

outbound SA from 63.230.113.162 to 65.114.226.162 (proxy 192.168.0

.0 to 192.168.1.0)

has spi 1010433820 and conn_id 3 and flags 4

lifetime of 28800 seconds

lifetime of 4608000 kilobytesIPSEC(key_engine): got a queue event...

IPSEC(initialize_sas): ,

(key eng. msg.) dest= 63.230.113.162, src= 65.114.226.162,

dest_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),

src_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-des esp-md5-hmac ,

lifedur= 28800s and 4608000kb,

spi= 0x97b8112(159088914), conn_id= 4, keysize= 0, flags= 0x4

IPSEC(initialize_sas): ,

(key eng. msg.) src= 63.230.113.162, dest= 65.114.226.162,

src_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),

dest_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-des esp-md5-hmac ,

lifedur= 28800s and 4608000kb,

spi= 0x3c39ff1c(1010433820), conn_id= 3, keysize= 0, flags= 0x4

VPN Peer: IPSEC: Peer ip:65.114.226.162 Ref cnt incremented to:2 Total VPN Peers

:1

VPN Peer: IPSEC: Peer ip:65.114.226.162 Ref cnt incremented to:3 Total VPN Peers

:1

return status is IKMP_NO_ERROR

As far as I can tell everything looks good, but for some reason I get Request times out's.

Here is the output when I type show crypto ipsec sa:

interface: outside

Crypto map tag: transam, local addr. 63.230.113.162

local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

current_peer: 65.114.226.162

PERMIT, flags={origin_is_acl,}

#pkts encaps: 3, #pkts encrypt: 3, #pkts digest 3

#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

#send errors 1, #recv errors 0

local crypto endpt.: 63.230.113.162, remote crypto endpt.: 65.114.226.162

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 3c39ff1c

inbound esp sas:

spi: 0x97b8112(159088914)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 4, crypto map: transam

sa timing: remaining key lifetime (k/sec): (4608000/27276)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x3c39ff1c(1010433820)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 3, crypto map: transam

sa timing: remaining key lifetime (k/sec): (4607999/27249)

IV size: 8 bytes

replay detection support: Y

As you can see I get a send error, I can't figure out what I am doing wrong.

I used this website to set this up, I didn't deviate except for IP addresses:

http://www.cisco.com/warp/public/110/38.html

Any assistance would be much appreciated.

Thanks,

Chris

4 Replies 4

ssoberlik
Level 4
Level 4

Try upgrading your 5.1(1) to 6.1(1).

I already tried this and it still doesn't work. I did notice one thing that disturbs me. When I type "show route" I get this entry among others:

inside 192.168.0.0 255.255.255.0 192.168.1.1 1 CONNECT static

192.168.0.0 is the network that I am trying to connect to, I think this route is screwing the routing up. I try to remove the route but it keeps saying,

"route already exists". Any Ideas on how to get rid of this route?

chris
Level 1
Level 1

I finally figured it out. There was nothing wrong with the VPN configuration, it ended up being a problem with the subnet mask on the internal interface of the remote PIX I was trying to connect to. The interface had a subnet mask of 255.255.252.0, which was causing the PIX to have a static CONNECT route of 192.168.0.0 rather then 192.168.1.0. Because the route was 192.168.0.0 and the internal interface of my PIX was also using a route of 192.168.0.0 the remote PIX wasn't routing anything back through the VPN. So I changed the subnet mask to 255.255.255.0 and everything is working great.

wiccisco
Level 1
Level 1

I hope by now you have found the answer but if not check your ACLs for allowing PING. Setup a CONDUIT to allow all ICMP or something. There is also a command called DEBUG ICMP TRACE I have found useful for allowing me to see if the ping is at least going out. You may see it gets out to the destination but is not returned. A clue. It could just be a routing issue or someone along the way filtering it.

Getting Started

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: