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

Site-to-Site VPN problem : PIX pkts no sa (send)

khayhuynh
Level 1
Level 1

Hi all,

I want to establish a VPN tunnel between 2 PIX515E, a site-to-site VPN.

I have used the wizard of the PDM.

First, the tunnel seems ok : I can ping hosts on remote site, telnet, etc.

But sometimes, the tunnel seems to be down: I cannot ping remote hosts for example anymore.

I think that when there is no traffic through the tunnel, it's ok that the tunnel is down. And when I try to ping remote hosts, I think that the tunnel should turn to up. Is it correct?

I look in the logs and I notice that whenever I try to ping/telnet a remote host, I generate in statistics:

"PIX pkts no sa (send)".

No packets are encrypted.

Could someone tell me where is the problem?

Thanks you for helping me!

4 Replies 4

khayhuynh
Level 1
Level 1

More information with a debug crypto isakmp:

ISAKMP (0:0): sending NAT-T vendor ID - rev 2 & 3

ISAKMP (0): beginning Main Mode exchange

crypto_isakmp_process_block:src:remote-pix, dest:A.B.C.D spt:500 dpt:500

OAK_MM exchange

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

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

ISAKMP: encryption 3DES-CBC

ISAKMP: hash SHA

ISAKMP: default group 2

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (basic) of 28800

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:remote-pix, dest:A.B.C.D 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:remote-pix, dest:A.B.C.D 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 keep alive: proposal=32767/32767 sec., actual=600/10 sec.

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 1370673357:51b2d0cdIPSEC(key_engine): got a queue event...

IPSEC(spi_response): getting spi 0x773f7309(2000646921) for SA

from remote-pix to A.B.C.D 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:remote-pix/500 Total VPN Peers:4

VPN Peer: ISAKMP: Peer ip:remote-pix/500 Ref cnt incremented to:1 Total VPN Peers:4

crypto_isakmp_process_block:src:remote-pix, dest:A.B.C.D spt:500 dpt:500

<-------until here, it seems Ok, i think?------->

<------- I compare theses lines with the lines I get when it works (in fact, I have multiple tunnels VPN on my PIX A, PIX A <--> PIX B, PIX A <--> PIX C, etc.) and I notice that theses 3 lines are missing....

OAK_QM exchange

oakley_process_quick_mode:

OAK_QM_IDLE

------->

<------- End of the debug: ------->

ISAKMP (0): processing NOTIFY payload 18 protocol 1

spi 0, message ID = 2482419244

return status is IKMP_NO_ERR_NO_TRANS

crypto_isakmp_process_block:src:remote-pix, dest:A.B.C.D spt:500 dpt:500

ISAKMP (0): processing DELETE payload. message ID = 2738261993, spi size = 16

ISAKMP (0): deleting SA: src A.B.C.D, dst remote-pix

return status is IKMP_NO_ERR_NO_TRANS

ISADB: reaper checking SA 0x10ffe3c, conn_id = 0 DELETE IT!

VPN Peer: ISAKMP: Peer ip:remote-pix/500 Ref cnt decremented to:0 Total VPN Peers:4

VPN Peer: ISAKMP: Deleted peer: ip:remote-pix/500 Total VPN peers:3IPSEC(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 remote-pix

ISADB: reaper checking SA 0x10d8c34, conn_id = 0

ISADB: reaper checking SA 0xfea484, conn_id = 0

ISADB: reaper checking SA 0x1106b14, conn_id = 0

Any Idea please?

Vikas Saxena
Cisco Employee
Cisco Employee

Hello,

Check this out

ISAKMP (0): speaking to a VPN3000 concentrator

It seems you are talking to a conc. rather a pix.

If this is really a conc. then the problem is the timers. Both devices have different timers.

Match the timers in both the devices and your problem will go away. This problem usually happens when the devices have different isa and ipsec timers. In one device the tunnel stays up and in another device the tunnel goes down. The device which says the tunnel goes down will initiate to bring up the tunnel and the initiation packet will be discarded by the device which has the tunnel as up..

Please check the other devce the debugs will rarely tell a lie.

Vikas

I think the remote firewall is a PIX.

are you sure that "ISAKMP (0): speaking to a VPN3000 concentrator " means that the remote FW is a VPN3000?

In many sites, I found this lines but it was VPN between 2 PIX. For example this one:

http://www.netcraftsmen.net/welcher/papers/pix04.pdf

---------------

About the timers, what do you mean by "timers"?

-Nat Keep Alive of IKE Policies?

-Keepalive of IKE policies?

-Retry of IKE policies?

- Security association LifeTime of Tunnel Policies?

Thanks U by advance...!

Hello,

As per the RFC the vendor can send its own ID so that extra capabilities can be negotiated.

The PIX is able to find out if it is speaking to another IOS box (Router), a conc. or another PIX.

My experience is that it rarely lies.

The timers are

isamkp timer (How long the isakmp tunnel stays up)

ipsec timers (after how much time the ipsec keys should re negotiate).

The PIX and the conc. have different timers, in case if your hunch is correct that it could be a pix try with isakmp keep alives 10 20. This will enable DPD in the tunnel.

Vikas

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: