One subnet that is going not going through the VPN encrypt phase.

[shenmue232]

Hi Guys, We have an issue with one subnet that is going not going through the VPN encrypt phase. Therefore the traffic isn’t being encrypted when going back to the remote ASA for that networks Running a capture also shows that the packets don’t receive an acknowledgement from the other side. The S stands for SYN, so the first part of the TCP three way handshake, and doesn’t get a SYN / ACK response. https://www.tunnelsup.com/packet-captures-on-cisco-asa/ 15:10:40.418145 192.168.19.28.59608 > 192.168.115.92.80: S 461273441:461273441(0) win 8192 At first I thought it could be due to the traffic being natted, which shouldn’t be done when going over a VPN, but the config hasn’t changed, I’ve double checked that. Why would this subnet not go through the encrypt phase, the crypto maps are mirrored correctly. This just happened one morning, the config never changed as we have cat tools monitoring the config. Any ideas?

[Rob Ingram]

Hi,
Can you run packet-tracer on your ASA and post the output here. E.g - "packet-tracer input inside tcp 192.168.19.28 www 192.168.115.92 www"

Can you also provide your configuration for us to look at?

[shenmue232]

I can't provide the config, but here is the packet tracer. The other networks in the crypto maps show the VPN encrypt phase, just not on the 19 network.

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.19.0 255.255.255.0 inside

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside in interface inside
access-list inside extended permit tcp any any eq www
Additional Information:

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

Phase: 6
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
nat-control
match ip inside 192.168.19.0 255.255.255.0 outside 192.168.115.0 255.255.255.0
NAT exempt
translate_hits = 3793, untranslate_hits = 0
Additional Information:

Phase: 7
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
nat-control
match ip inside any outside any
dynamic translation to pool 1 ( [Interface PAT])
translate_hits = 1576875518, untranslate_hits = 201112143
Additional Information:

Phase: 8
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
nat-control
match ip inside any outside any
dynamic translation to pool 1 ( [Interface PAT])
translate_hits = 1576875518, untranslate_hits = 201112143
Additional Information:

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

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

Phase: 11
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop using egress ifc outside
adjacency Active
next-hop mac address hits 35780

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

[Rob Ingram]

Well this subnet isn't even attempting to go through the VPN, I'd check the crypto map to ensure the source subnet and the remote subnet is included.

Can you provide the specific acl and objects referenced in the acl?

[shenmue232]

Found out it was a missing access list in the crypto map! looks like its resolved now!

[Rob Ingram]

Ok good, glad I could have been helpful in helping you resolve this issue

[shenmue232 · Accepted solution]

Thanks for all your help on this RJI.