Cisco ASA site-to-site tunnel up but traffic not reaching other end.

[mmzzaq]

Hi,

I'm trying to create a site-to-site tunnel from Site A (Asa 5506-X) to Site B (Meraki MX64). The Meraki reports the tunnel as up (green button) and I believe the Asa does the same:

<EDITTED OUT FOR SECURITY PURPOSES>

Here's a diagram of what I'm trying to establish:

<EDITTED OUT FOR SECURITY PURPOSES>

Also, I attached my #show run to this post <EDITTED OUT FOR SECURITY PURPOSES>. If anymore information is needed I would be more than happy to provide.

Problem: VPN traffic destined for either Site A (10.56.0.0) or Site B (10.50.0.0) doesn't reach the other end. So for example when I try RDP from 10.56.0.2 (PCA) to 10.50.0.2 (PCB), it just times out because the traffic doesn't reach the destination. Same for ping or any other traffic and the other way around has the same problem. Whenever I traceroute from a machine in Site B it just shows the gateway and all other hops time out. Whenever I traceroute from a machine in Site A it doesn't show the gateway and all hops timeout. Note: no firewall is active on any of the machines.

Both gateways have their ACL's set to bypass for VPN traffic. The Asa on Site A has a cryptomap which should allow the vpn traffic. I first thought it might be a routing problem since #show route on the Asa doesn't show a route for Site B, but after some reading up on site-to-site, this seems to be normal (correct?). Further more VPN traffic is set to be exempted from NAT.

Can anyone tell me what I'm doing wrong? Note: I have setup the site-to-site connection with ASDM wizard, I'm not super familiar with Asa and/or commands.

Thanks in advance.

[Bogdan Nita]

Can you post the output form the following command on the ASA, after some traffic has been generated:

show crypto ipsec sa peer 222.222.222.222

Also I am unable to see the attached config, maybe you can post it again.

[mmzzaq]

# show crypto ipsec sa peer 222.222.222.222
peer address: 222.222.222.222
    Crypto map tag: outside_map, seq num: 1, local addr: 111.111.111.111

      access-list outside_cryptomap extended permit ip 10.56.0.0 255.255.0.0 10.50.0.0 255.255.0.0
      local ident (addr/mask/prot/port): (10.56.0.0/255.255.0.0/0/0)
      remote ident (addr/mask/prot/port): (10.50.0.0/255.255.0.0/0/0)
      current_peer: 222.222.222.222


      #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 2, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 111.111.111.111/0, remote crypto endpt.: 222.222.222.222/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 0B926E56
      current inbound spi : B4B692EA

    inbound esp sas:
      spi: 0xB4B692EA (3031864042)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, IKEv1, }
         slot: 0, conn_id: 28672, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3915000/28762)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x0B926E56 (194145878)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, IKEv1, }
         slot: 0, conn_id: 28672, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914999/28762)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

Regarding the config not showing: can you try to refresh the thread? (ctrl+f5). I had that problem earlier too (because of an edit). Refreshing the thread helped :)

[Bogdan Nita]

I was able to see the config file and the configuration on the ASA seems to be ok.

Based on the outputs you posted the vpn tunnel is coming up and traffic is being sent from the ASA side, but there is no response from the Meraki side.

This is usually due to routing or NAT configuration issues on the Meraki side, but based on your diagram it should be a simple config and I can't think of something being miss-configured and have the vpn tunnel up.

Can you configure a packet capture on the Merakis inside interface to see if the traffic is actually being sent to the host and that the hosts is responding ?

[mmzzaq]

Thank you Bogdan for looking at the config and confirming that it looks ok. I will try do a capture as soon as I'm in the offce (tomorrow) and will report back once I know more.

edit: Unfortunately not been able to troubleshoot today, I will report back friday.

[Richard Burts]

I agree that the output of show crypto IPsec sa does show that the tunnel is coming up and is sending packets to the peer but is not receiving any encrypted packets from the Meraki.

      #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

The ASA seems to be doing what it should and you need to look at Meraki to find the configuration issue. I have seen this symptom of one way traffic over site to site VPN and sometimes it is due to some routing issue and sometimes to issues about NAT (not exempting the VPN traffic from translation).

HTH

Rick

[mmzzaq]

Packet captures showed no VPN traffic coming through on either of the ends.

As last resort I tried to make the tunnel work by using only 3DES for encryption and SHA1 at the Phase2 settings in the Meraki and the same settings at IPsec proposal section on the Asa. That did the trick, I can reach both subnets now (pretty happy atm :) ).

Next week I'm gonna try adding more secure algorithms one by one with a little bit of trial and error.

Thanks you both for looking at my config and the help/tips.

[Richard Burts]

Thanks for letting us know that when you reconfigured using different parameters that the tunnel did begin to work and to transmit and receive encrypted traffic. I believe this confirms that something got out of sync between the peers or was misconfigured on one peer. Now that you have it working I am confident that you can change the config to use more secure algorithms and it should continue to work.

HTH

Rick

[Noside]

What would be the solution for this if I am not receiving enrcypted packages as shown below

   #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

[Richard Burts]

My first observation is that since you are encrypting but not decrypting that it means that you are not receiving encrypted traffic from your peer. It might be possible that you have an access policy that is not accepting ESP protocol traffic from the peer.

My second observation is that it is more likely that the issue is something on the remote peer. I have seen issues with routing logic cause this issue (traffic is not being forwarded through the tunnel or through the interface with the crypto map). And I have seen issues with address translation cause this issue (traffic for the vpn is being translated when it should not be).

HTH

Rick