11-27-2017 08:54 AM - edited 03-12-2019 04:46 AM
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.
11-27-2017 11:56 AM
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.
11-27-2017 12:44 PM
# 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 :)
11-28-2017 12:07 AM
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 ?
11-28-2017 07:12 AM - edited 11-29-2017 09:10 AM
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.
11-28-2017 07:40 AM
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
12-01-2017 09:06 AM - edited 12-01-2017 09:07 AM
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.
12-05-2017 01:41 PM
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
05-02-2019 11:15 AM
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
05-03-2019 04:51 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide