send errors in IPsec vpn and nothing else

[Krasnoperov]

Hi I have a problem

my network look like this

host->ciscoRouter1---GRE tunnel--ciscoRouter2->IPsec VPN->juniper router

Packet coming from host to ciscoRouter2 succefuly,

IPsec VPN is up

sh crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst             src             state          conn-id slot status

xx.xx.xx.23    xx.xxx.xx.54    QM_IDLE           1010    0 ACTIVE

BUT

When I ping remote host on other side of ipsec vpn, icmp fail and only "

send errors" counter increments, other counters all = 0, why could be so?

sh crypto ipsec sa

interface: Vlan2

    Crypto map tag: TeraD_CrMap, local addr xx.xxx.xx.54

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.1.1.10/255.255.255.255/0/0)

   remote ident (addr/mask/prot/port): (xxx.xx.xx.18/255.255.255.255/0/0)

   current_peer xxx.xx.xx.23 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

    #pkts compressed: 0, #pkts decompressed: 0

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

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 45, #recv errors 0

     local crypto endpt.: xx.xxx.xx.54, remote crypto endpt.: xxx.xx.xx.23

     path mtu 1500, ip mtu 1500

     current outbound spi: 0x0(0)

[raga.fusionet]

Hi,

Your phase 2 is not completing (IPSec). If it completes you should see SPI Numbers and a Security Assocation created when you do the show crypto ipsec sa.

I would check that the interesting traffic matches and that you have the same transform set and policies for the tunnel.

Once phase two completes you should start seeing encrypted packets instead of send errors.

You can also enable debug crypto ipsec. It should give more information about why the tunnel is failing.

HTH.

Raga

[donlerche]

I am posting same reply I have put on another thread with similar issue, as no solution has been given..

OK, the biggest clue is if you do a "show crypto ipsec sa" and this will list all tunnels you have configured. You should notice that there is a entry for each line you have in the crypto map you are using to identify "interesting" traffic, the key is that each tunnel entry has a "local" and "remote" identifier corresponding to the "source" and "destination" entry in the matching line in crypto map acl. THESE NEED TO MATCH AT THE OTHER END (but in opposite direction) for the tunnel to be established.

In my case, I had a different subnet mask in the ACL for the source subnet at one end to the destination in the crypto map at the other end, so even though the crypto map was showing hits on identifying the interesting traffic, the "local" identifier at one end didn't match the "remote" identifier at the other end. Simple fix once you know this :¬)

Hope this helps

[Ricky Sandhu]

Thank you.  This solved the issue on my end.  Remote side wasn't configured with the same ACL entries and now all is working.