cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2373
Views
8
Helpful
27
Replies

Traffic not passing |#pkts encaps: 0, #pkts encrypt

tshabbircisco
Level 1
Level 1

 

Hello,

We are facing weird issue, suddenly working VPN went down, while reviewing, we found that tunnel is up however traffic is not passing. I can see pkts encap:0 and pkts decaps increasing. I have verified ACL/NAT thoroughly but unable to find the root cause.

Additionally, packet tracer also looks good. Urgent help is required. Here are some Environment details and some outputs


Environment:
OnPrem
Cisco ASA 5545
ASA Ver: 9.2
ASDM Ver: 7.2
ASA Interesting Network: 10.20.31.0/24

Azure Side
Routed :
VNET Interesting Traffic: 10.20.80.0/20


#show crypto ipsec sa peer AZ.AZ.AZ.AZ
peer address: AZ.AZ.AZ.AZ
Crypto map tag: Outside-W_map, seq num: 56, local addr: ASA-ASA-ASA-ASA

access-list Outside-W_cryptomap_51 extended permit ip 10.20.31.0 255.255.255.0 10.20.80.0 255.255.240.0
local ident (addr/mask/prot/port): (10.20.31.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.20.80.0/255.255.240.0/0/0)
current_peer: AZ.AZ.AZ.AZ


#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 9722, #pkts decrypt: 9722, #pkts verify: 9722
#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

local crypto endpt.: ASA-ASA-ASA-ASA/500, remote crypto endpt.: AZ.AZ.AZ.AZ/500
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: 2BB3FCD4
current inbound spi : F48DFC9C

inbound esp sas:
spi: 0xF48DFC9C (4102945948)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 142692352, crypto-map: Outside-W_map
sa timing: remaining key lifetime (kB/sec): (4331501/2054)
IV size: 16 bytes
replay detection support: N
outbound esp sas:
spi: 0x2BB3FCD4 (733215956)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 142692352, crypto-map: Outside-W_map
sa timing: remaining key lifetime (kB/sec): (4285440/2054)
IV size: 16 bytes
replay detection support: N

show vpn-sessiondb detail l2l filter ipaddress AZ.AZ.AZ.AZ

Session Type: LAN-to-LAN Detailed

Connection : AZ.AZ.AZ.AZ
Index : 34837 IP Addr : AZ.AZ.AZ.AZ
Protocol : IKEv2 IPsec
Encryption : IKEv2: (1)AES256 IPsec: (2)AES256
Hashing : IKEv2: (1)SHA1 IPsec: (2)SHA1
Bytes Tx : 4413844 Bytes Rx : 11750792
Login Time : 21:18:53 EDT Tue May 2 2023
Duration : 11h:27m:01s

IKEv2 Tunnels: 1
IPsec Tunnels: 2

IKEv2:
Tunnel ID : 34837.1
UDP Src Port : 500 UDP Dst Port : 500
Rem Auth Mode: preSharedKeys
Loc Auth Mode: preSharedKeys
Encryption : AES256 Hashing : SHA1
Rekey Int (T): 28800 Seconds Rekey Left(T): 14948 Seconds
PRF : SHA1 D/H Group : 2
Filter Name :

IPsec:
Tunnel ID : 34837.3
Local Addr : 10.20.31.0/255.255.255.0/0/0
Remote Addr : 10.20.80.0/255.255.240.0/0/0
Encryption : AES256 Hashing : SHA1
Encapsulation: Tunnel
Rekey Int (T): 3600 Seconds Rekey Left(T): 1406 Seconds
Rekey Int (D): 4608000 K-Bytes Rekey Left(D): 4607974 K-Bytes
Idle Time Out: 30 Minutes Idle TO Left : 29 Minutes
Bytes Tx : 0 Bytes Rx : 500492
Pkts Tx : 0 Pkts Rx : 9878

IPsec:
Tunnel ID : 34837.4
Local Addr : 10.20.31.0/255.255.255.0/0/0
Remote Addr : 10.35.0.0/255.255.0.0/0/0
Encryption : AES256 Hashing : SHA1
Encapsulation: Tunnel
Rekey Int (T): 3600 Seconds Rekey Left(T): 3301 Seconds
Rekey Int (D): 4608000 K-Bytes Rekey Left(D): 4607965 K-Bytes
Idle Time Out: 30 Minutes Idle TO Left : 30 Minutes
Bytes Tx : 2725786 Bytes Rx : 6715217
Pkts Tx : 49620 Pkts Rx : 48589

packet-tracer input inside-D tcp 10.20.31.130 111 10.20.80.11 80

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 via 212.X.X.X, Outside-W

Phase: 4
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (Inside-D,Outside-W) source static NETWORK_OBJ_10.20.31.0_24 NETWORK_OBJ_10.20.31.0_24 destination static DM_INLINE_NETWORK_32 DM_INLINE_NETWORK_32 no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface Outside-W
Untranslate 10.20.80.11/80 to 10.20.80.11/80

Phase: 5
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Inside-access-IN in interface Inside-D
access-list Inside-access-IN extended permit ip any any
Additional Information:

Phase: 6
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:

Phase: 7
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (Inside-D,Outside-W) source static NETWORK_OBJ_10.20.31.0_24 NETWORK_OBJ_10.20.31.0_24 destination static DM_INLINE_NETWORK_32 DM_INLINE_NETWORK_32 no-proxy-arp route-lookup
Additional Information:
Static translate 10.20.31.130/111 to 10.20.31.130/111

Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 12
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (Inside-D,Outside-W) source static NETWORK_OBJ_10.20.31.0_24 NETWORK_OBJ_10.20.31.0_24 destination static DM_INLINE_NETWORK_32 DM_INLINE_NETWORK_32 no-proxy-arp route-lookup
Additional Information:

Phase: 13
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 14
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 15
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 16
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 17
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 18
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1033661206, packet dispatched to next module

Result:
input-interface: Inside-D
input-status: up
input-line-status: up
output-interface: Outside-W
output-status: up
output-line-status: up
Action: allow

1 Accepted Solution

Accepted Solutions

@tshabbircisco 

Revisiting your initial post , i see there is only single ikev2 tunnel active on ASA which means there cannot be any overlapping ACL . In that case i suspect you are hitting following bug https://bst.cisco.com/bugsearch/bug/CSCup37416 . I have handled many cases with identical issues where the shared bug was concluded . 

Since there is no fix for it , i suggest you try the workaround mentioned in bug itself .  

Regards
Salman Mahajan 
If this helps with your issue , mark this helpful 












S

View solution in original post

27 Replies 27

Amine ZAKARIA
Spotlight
Spotlight

Hello,

Is there any asymetric routing ? do you receive any 10.20.31.0 traffic destined to 10.20.80.0 on the inside interface of the firewall ?

Regards!

Hi Amine,

We do not have 10.20.80.0/20 other than VPN interesting traffic. However, I do have another VPN (10.20.45.0/24)  which also connected to  10.20.80.0. But not sure if that creating asymetric routing

P3HR-ASA/sec/act# sh route 10.20.80.0

% Subnet not in table

 

Hello @tshabbircisco ,

The other VPN exist on another firewall or same firewall ?

Can you share the output of show route | b 10.20.80 you should see it as V

Regards!

 

@tshabbircisco ,

If same FW that make sense for the issue, try to remove the 10.20.31.0 going to 10.20.80.0 from the interesting traffic in this tunnel and add 10.20.31.0 -> 10.20.80.0 on the other tunnel, but make sure to know the impact before doing the change.

Regards!

Yes, Other VPN exist on same firewall but (10.20.45.0/24) is different firewall than (10.20.80.0/20)

sh route  

P3HR-ASA/sec/act# sh route | inc 10.20.80
P3HR-ASA/sec/act#

Hello,

The firewall see the remote 10.20.80.0/20 from the other tunnel you have mentionned, if it is safe try the suggestion to pass the 10.20.31.0 to other VPN.
Regards!

Salman Mahajan
Cisco Employee
Cisco Employee

@tshabbircisco 
Packet-tracer output looks fine . You would need to check if you are seeing the traffic from Local Subnet ( 10.20.31.0 ) destined to Remote Subnet ( 10.20.80.0 ) on ingress interface .

1. Do a packet capture on the ingress ( Inside-D)  interface 
capture capin interface Inside-D match ip host 10.20.31.x host 10.20.80.x 

2. If the capture shows traffic destined to 10.20.80.x , then check if its being dropped by asp 
capture asp type asp-drop match match ip host 10.20.31.x host 10.20.80.x 

Let me know what do you see ! 

Regards
Salman 

Hi Salman,

Yes, we seeing traffic from 10.20.30.0/24 to 10.20.80.0/20, 

1:

capture capin type raw-data interface Inside-D [Capturing - 6012 bytes]
match ip any 10.20.80.0 255.255.240.0

P3HR-ASA/sec/act# sh cap capin

90 packets captured

1: 20:22:08.065731 10.20.31.107.54557 > 10.20.80.11.1521: SWE 360007764:360007764(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
2: 20:22:09.498341 10.20.31.130 > 10.20.80.4: icmp: echo request
3: 20:22:11.062115 10.20.31.107.54557 > 10.20.80.11.1521: SWE 360007764:360007764(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
4: 20:22:14.514270 10.20.31.130 > 10.20.80.4: icmp: echo request
5: 20:22:17.077983 10.20.31.107.54557 > 10.20.80.11.1521: S 360007764:360007764(0) win 8192 <mss 1460,nop,nop,sackOK>
6: 20:22:19.517993 10.20.31.130 > 10.20.80.4: icmp: echo request
7: 20:22:24.507557 10.20.31.130 > 10.20.80.4: icmp: echo request
8: 20:22:29.497090 10.20.31.130 > 10.20.80.4: icmp: echo request
9: 20:22:30.259767 10.20.31.107.54735 > 10.20.80.11.1521: SWE 2484228009:2484228009(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
10: 20:22:33.275162 10.20.31.107.54735 > 10.20.80.11.1521: SWE 2484228009:2484228009(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
11: 20:22:34.518085 10.20.31.130 > 10.20.80.4: icmp: echo request
12: 20:22:39.282379 10.20.31.107.54735 > 10.20.80.11.1521: S 2484228009:2484228009(0) win 8192 <mss 1460,nop,nop,sackOK>
13: 20:22:39.512577 10.20.31.130 > 10.20.80.4: icmp: echo request
14: 20:22:44.512684 10.20.31.130 > 10.20.80.4: icmp: echo request
15: 20:22:49.508564 10.20.31.130 > 10.20.80.4: icmp: echo request
16: 20:22:51.508945 10.20.31.107.54921 > 10.20.80.11.1521: SWE 4006345333:4006345333(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
17: 20:22:54.507465 10.20.31.130 > 10.20.80.4: icmp: echo request
18: 20:22:54.517353 10.20.31.107.54921 > 10.20.80.11.1521: SWE 4006345333:4006345333(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
19: 20:22:57.791554 10.20.31.107.54978 > 10.20.80.11.1521: SWE 2527693871:2527693871(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
20: 20:22:59.507618 10.20.31.130 > 10.20.80.4: icmp: echo request
21: 20:23:00.517581 10.20.31.107.54921 > 10.20.80.11.1521: S 4006345333:4006345333(0) win 8192 <mss 1460,nop,nop,sackOK>
22: 20:23:00.799809 10.20.31.107.54978 > 10.20.80.11.1521: SWE 2527693871:2527693871(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
23: 20:23:04.512165 10.20.31.130 > 10.20.80.4: icmp: echo request
24: 20:23:06.444526 10.20.31.243.53030 > 10.20.80.11.1521: SWE 334383102:334383102(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
25: 20:23:06.815646 10.20.31.107.54978 > 10.20.80.11.1521: S 2527693871:2527693871(0) win 8192 <mss 1460,nop,nop,sackOK>
26: 20:23:09.441108 10.20.31.243.53030 > 10.20.80.11.1521: SWE 334383102:334383102(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
27: 20:23:09.501225 10.20.31.130 > 10.20.80.4: icmp: echo request
28: 20:23:14.509220 10.20.31.130 > 10.20.80.4: icmp: echo request
29: 20:23:15.440986 10.20.31.243.53030 > 10.20.80.11.1521: S 334383102:334383102(0) win 8192 <mss 1460,nop,nop,sackOK>
30: 20:23:19.197362 10.20.31.107.55160 > 10.20.80.11.1521: SWE 869889558:869889558(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
31: 20:23:19.506413 10.20.31.130 > 10.20.80.4: icmp: echo request
32: 20:23:22.194432 10.20.31.107.55160 > 10.20.80.11.1521: SWE 869889558:869889558(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

 


33: 20:23:24.506489 10.20.31.130 > 10.20.80.4: icmp: echo request
34: 20:23:28.205647 10.20.31.107.55160 > 10.20.80.11.1521: S 869889558:869889558(0) win 8192 <mss 1460,nop,nop

 

@tshabbircisco 

++ Did you get a chance to run asp capture for interesting traffic  to confirm it is not getting dropped . 
++ If there is no ASP drop , i am inclined to believe there is a possibility of overlapping Crypto ACL  . Is there any other S2S VPN currently active on ASA ? 

Regards
Salman 

@tshabbircisco 

Revisiting your initial post , i see there is only single ikev2 tunnel active on ASA which means there cannot be any overlapping ACL . In that case i suspect you are hitting following bug https://bst.cisco.com/bugsearch/bug/CSCup37416 . I have handled many cases with identical issues where the shared bug was concluded . 

Since there is no fix for it , i suggest you try the workaround mentioned in bug itself .  

Regards
Salman Mahajan 
If this helps with your issue , mark this helpful 












S

@tshabbircisco 
Stale VPN Context entries cause ASA to stop encrypting traffic seems to be fixed in 9.14.1 version . Since you are running older version you can try mentioned workaround in the Bug . 

Some Potential workarounds that i have seen helping are below :- 
1. Reboot ASA ( to remove stale entry ) . 
2. Move to Ikev1 ( if it is feasible ) 

FYI :- If you need help in analysing if the interesting traffic is hitting stale asp entry on ASA , i can help with that . For that i require certain outputs ( may require you to share via email ) . 


Regards
Salman Mahajan 
If this helps with your issue , mark this helpful 


@Salman Mahajan 

Thank you for reviewing in detail. 

1. Reboot ASA ( to remove stale entry ) . 

Yes, We can reboot in off time. However, we do have Active-Passive pair, Not sure do we need to reboot both. 
2. Move to Ikev1 ( if it is feasible ) 

We cannot move to IKEv1 due to other side limitations. 

FYI :- If you need help in analysing if the interesting traffic is hitting stale asp entries on ASA , i can help with that . For that i require certain outputs ( may require you to share via email )

Yes, Definitely , Please advise how can we start on this

 

@Salman Mahajan 

Hi Salman,

As suggested i deleted inactive SA and my issue is resolved Immediately. I must admit the efforts you have put and the Cisco community at its best. Credit go to this forum facility as i was facing issue since few days and unable to find any clue.

P3HR-ASA/sec/act# sh crypto ipsec sa inactive

Checking for inactive IPsec SAs...
Inactive inbound SA: SPI: 0x1A880F5C, state: dead
Inactive outbound SA: SPI: 0x7BF6D766, state: dead
Inactive inbound SA: SPI: 0x88C4575C, state: dead
Inactive outbound SA: SPI: 0xF358EDFA, state: dead
Inactive inbound SA: SPI: 0xC015F2A5, state: dead
Inactive outbound SA: SPI: 0x6986DB82, state: dead
Inactive inbound SA: SPI: 0xA8206443, state: dead
Inactive outbound SA: SPI: 0x4A47C21E, state: dead
Inactive IPsec SAs: 8
P3HR-ASA/sec/act#
P3HR-ASA/sec/act#
P3HR-ASA/sec/act#
P3HR-ASA/sec/act#
P3HR-ASA/sec/act# clear crypto ipsec sa inactive
Inactive inbound SAs deleted: 4
Inactive outbound SAs deleted: 4

clear crypto ipsec sa inactive

@Salman Mahajan 

As clearing inactive SA solves the issue. Should i use this as well 

1)Disable data-based rekeying:
"crypto map set security-association lifetime kilobytes unlimited"