Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

PIX to PIX VPN

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
Bronze

Re: PIX to PIX VPN

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

Community Member

Re: PIX to PIX VPN

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?

Community Member

Re: PIX to PIX VPN

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.

Community Member

Re: PIX to PIX VPN

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.

134
Views
0
Helpful
4
Replies
CreatePlease to create content