Site-2-Site VPN tunnel established ikev1 in asa but traffic not passing

[jrnetipsec]

Hi Community,

I am stuck in here as, VPN is successfully established between DC & Site1 but traffic (icmp or any other) is not flowing. Kindly help. Below are the two site IKV1 configuration.

Site 1: 

object-group network Datacenter_nw
network-object 192.168.20.0 255.255.255.0
network-object 10.55.1.0 255.255.255.0

object network LAN
subnet 10.184.2.0 255.255.255.0

access-list SEATFWtoDatacenter extended permit ip object LAN object-group Datacenter_nw

nat (inside_1,outside) source static LAN LAN destination static Datacenter_nw Datacenter_nw no-proxy-arp route-lookup

crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 28800

crypto ikev1 enable outside
crypto isakmp identity address

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
ikev1 pre-shared-key *****

crypto ipsec ikev1 transform-set myvpnset esp-aes-256 esp-sha-hmac

crypto map SEATVPN 1 match address SEATFWtoDatacenter
crypto map SEATVPN 1 set peer x.x.x.x
crypto map SEATVPN 1 set ikev1 transform-set myvpnset

IKEv1 SAs:

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: x.x.x.x
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : aes-256 Hash : SHA
Auth : preshared Lifetime: 28800
Lifetime Remaining: 27848

There are no IKEv2 SAs

NATTr.

1 (inside_1) to (outside) source static LAN LAN destination static Datacenter_nw Datacenter_nw no-proxy-arp route-lookup
translate_hits = 7618, untranslate_hits = 7618

access-list SEATFWtoDatacenter; 10 elements; name hash: 0xbf70aa0c
access-list SEATFWtoDatacenter line 1 extended permit ip object LAN object-group Datacenter_nw (hitcnt=42) 0xf67bb5c9
access-list SEATFWtoDatacenter line 1 extended permit ip 10.184.2.0 255.255.255.0 10.55.1.0 255.255.255.0 (hitcnt=39943) 0x862fb856

DC :

object-group network Datacenter_lan
network-object 192.168.20.0 255.255.255.0
network-object 10.0.0.0 255.0.0.0
object-group network SeattleFW_lan
network-object 10.184.2.0 255.255.255.0

access-list DatacentertoSEATFW extended permit ip object-group Datacenter_lan object-group SeattleFW_lan

nat (inside,outside) 1 source static Datacenter_lan Datacenter_lan destination static SeattleFW_lan SeattleFW_lan no-proxy-arp route-lookup

crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 28800

crypto ikev1 enable outside
crypto isakmp identity address


tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
ikev1 pre-shared-key *****

crypto ipsec ikev1 transform-set myvpnset esp-aes-256 esp-sha-hmac

crypto map outside_map2 60 match address DatacentertoSEATFW
crypto map outside_map2 60 set peer x.x.x.x
crypto map outside_map2 60 set ikev1 transform-set myvpnset

30 IKE Peer: 96.79.192.233
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE
Encrypt : aes-256 Hash : SHA
Auth : preshared Lifetime: 28800
Lifetime Remaining: 27770

NAT Tr.

1 (inside) to (outside) source static Datacenter_lan Datacenter_lan destination static SeattleFW_lan SeattleFW_lan no-proxy-arp route-lookup
translate_hits = 11, untranslate_hits = 11

Access List-

access-list DatacentertoSEATFW; 2 elements; name hash: 0x6a9b85c7
access-list DatacentertoSEATFW line 1 extended permit ip object-group Datacenter_lan object-group SeattleFW_lan (hitcnt=0) 0x1cf33b31
access-list DatacentertoSEATFW line 1 extended permit ip 10.0.0.0 255.0.0.0 10.184.2.0 255.255.255.0 (hitcnt=32) 0x4bb5c8a0

Thanks in advance.

[Rob Ingram]

Hi,

So you've got an IKE/ISAKMP SA, but do you have a IPSec SA? What is the output of show crypto ipsec sa?

Do you see the encap|decap increasing?

Are you pinging from the ASA itself or a device behind the ASA?

[jrnetipsec]

Continuous ping is running from 10.55.1.x to 10.184.2.x.
I observed the same packets are not encap/decap.

Here is the output.
Site1:
#pkts encaps: 516, #pkts encrypt: 516, #pkts digest: 516
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 460, #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

DC:
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 516, #pkts decrypt: 516, #pkts verify: 516
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #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

[Rob Ingram]

Site1 is sending (encaps) and DC is receiving (decaps), but DC is not returning the traffic (no encap). Checking the routing on DC end.

[jrnetipsec]

Can you elaborate please ? following is only routing in dc side:
route outside 0.0.0.0 0.0.0.0 x.x.x.x 1
route inside 10.55.1.0 255.255.255.0 10.1.20.1 1

[Rob Ingram]

What about the DC switch or router, does it have a route back for the Site1 networks to go via the ASA? If the DC ASA isn't encrypting traffic (which the output confirms) it probably means the traffic isn't getting to the ASA to be sent over the VPN tunnel.

Also you object on DC is different to what you've defined on Site1 ASA.

object-group network Datacenter_lan
network-object 192.168.20.0 255.255.255.0
network-object 10.0.0.0 255.0.0.0

[jrnetipsec]

I have changed the object to same as site1. But the issue is same. There is no router or switch. between asa.

[Rob Ingram]

Fine, the inconsistency was an observation.

What about the routing?

If DC ASA is not encrypting the traffic (which the output confirms) that chances are the traffic is not reaching the ASA. What is connected to the ASA on DC? A switch, if so please provide information on it's routing table

[jrnetipsec]

Which traffic is not reaching dc (lan) to asa or from site 1 (lan) to dc asa ? there is managed switch but very little config. nothing important.

[Rob Ingram]

Site1:
#pkts encaps: 516, #pkts encrypt: 516, #pkts digest: 516
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

DC:
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 516, #pkts decrypt: 516, #pkts verify: 516

Whatever traffic being sent from Site1 is being encrypted on Site1 ASA, it's then decrypted on DC ASA....but there is no traffic encrypted on the DC ASA so therefore nothing decrypted on Site1 ASA. So potentially the traffic on the DC network is not being routed to the DC ASA in the first place.

Is the managed switch at the DC the default gateway for the devices there?

[Sheraz.Salim]

This clearly show there is a routing issue

make sure you have routing in place between your interested ACL. For example. Ping from firewall to your interested acl ip adress same on the other remote site too

[jrnetipsec · Accepted solution]

Hi everyone,

Eventually, we figured it out. The issue was not with the routing as I have checked ASA can ping internal network and other VPN tunnel working great only issue with this site is that there was another NAT & ACL present which overlap the new VPN tunnel and that is why traffic was not passing through it. After removing it and re configuring the ACL's & NAT traffic is now flowing smoothly into the VPN tunnel.

Thanks for the support.

[Sheraz.Salim]

interesting config looks ok.

run these command and share the output

debug crypto conditon peer xxxxx     (This is the remote public ip address of the other side)

logging monitor debug

if on ssh connection run this command

ter monitor

And to disable it enter

terminal no monitor

[jrnetipsec]

logging monitor debug. Command is not working ASA5506.

[Hulk8647]

his object-group networks are inconsistent. I know that sometimes ASA dont like that at all. On the site-1 he has 10.55.1.0/24

and on the DC he has 10.0.0.0/8

Could that be an issue?