L2L VPN send errors

Jouni Forss · ‎12-30-2008

Hi,

Would just like to confirm the meaning of the "#send errors" in the show crypto ipsec sa peer <ip> command output.

Trying to troubleshoot a L2L VPN connection. For some reason the customer isnt able to access the network behind our firewall. The actual L2L VPN connection has worked before now for some reason doesnt.

I can get the tunnel up by using icmp with the source address from a range originally assigned for the connection. The show crypto session remote <ip> shows the tunnel briefly in UP-IDLE state. So seems the tunnel configuration is fine between the two peers?

Though my actual question is what are the "#send errors" output result of spesifically? When I use icmp from our side to their firewall i dont see increase in the hitcount for encapsulated packets but see #send errors. Still the tunnel goes UP-IDLE state after sending the icmp messages.

I tried to find an explanation for all the information the show crypto ipsec sa peer <ip> commands output gives but couldnt find any.

Any help would be appriciated

ebreniz · ‎01-05-2009

show crypto isakmp sa, it will display the following information:

Total : 1

Embryonic : 0

dst src state pending created

209.161.102.132 209.161.102.134 QM_IDLE 0 1

The state in the above sample is QM_IDLE which means that the phase 1 and phase 2 is up

and the created is one for that specific connection. There are situations in which phase 1

passes (Main Mode) and phase 2 fails but it shows state as QM_IDLE in that case created

will show 0 which means the tunnel wasn't created meaning a problem on phase 2. Normally

this is caused because of the crypto map not applied to the interface outside. If there is

a problem on phase one it will show state as MM_NO_STATE or MM_XX which means phase one

not passing. This happens when having a policy mismatch or even a password mismatch.

Now the command show crypto ipsec sa is useful for checking the phase two information:

interface: outside

Crypto map tag: des, local addr. 209.161.102.132

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

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

current_peer: 209.161.102.134

PERMIT, flags={origin_is_acl,}

#pkts encaps: 18, #pkts encrypt: 18, #pkts digest 18

#pkts decaps: 20, #pkts decrypt: 20, #pkts verify 20

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 209.161.102.132, remote crypto endpt.: 209.161.102.134

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 9380d2c7

inbound esp sas:

spi: 0xc72667a(208823930)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5, crypto map: des

sa timing: remaining key lifetime (k/sec): (4607995/27613)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x9380d2c7(2474693319)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 6, crypto map: des

sa timing: remaining key lifetime (k/sec): (4607998/27609)

IV size: 8 bytes

replay detection support: Y

outbound ah sas:

outbound pcp sas:

In the previous sample it shows packets being encrypted and decrypted. In order to verify

that the tunnel is really up for phase two you need to check all

inbound esp sas: and outbound pcp sas: if all those sas are empty it will mean that phase

two wasn't created.

Now the command for ssh. First you need to create a hostname and a domain for the pix:

hostname test

domain test.com --> The domain name must be FQDN.

then create the keys

crypto ca generate rsa key 1024

then the ssh commands for ssh. If you need for example the host 209.55.44.6 to enter then:

ssh 209.55.44.6 255.255.255.255 outside