VPN IPSec VPN connection to Sonicwall

[Scomage]

I am trying to create a VPN connection to a Sonicwall running gen 7 os.  We already have two VPNs from the same Cisco to two other clients running gen 7 Sonicwalls.  I copied all of the settings and the Sonicwall shows connected with the green dot but no data is transferred.  I am using ASDM as I am not proficient with the Cisco CLI interface.  I am looking for any advice on how to diagnose this issue.  The Cisco is provided by our hosting company and we do not have the ability to update any versions without their permission.

Cisco ASA 5515 version 9.8(4)29

ASDM version7.12(2)

Sonicwall TZ 270 version  7.1.3-7015

Please advise what information from the Cisco will be helpful to diagnose this and how to extract it.

Thanks in advance for any assistance.

[MHM Cisco World]

Copy config? Are you copy ACL of vpn also??

MHM

[Scomage]

I visually did a "stare and compare" to create the new vpn config.  What data can i export from the Cisco to assist with the diagnosis.

[Sheraz.Salim]

When a VPN tunnel between a SonicWall Gen 7 (TZ 270) and a Cisco ASA 5515 (9.8(4)29) shows as "up" (green dot) but no data passes, this typically points to a routing, NAT, or access-list (ACL) issue rather than a basic tunnel negotiation problem. Below are steps and key information to gather from the Cisco ASA using ASDM to diagnose the issue.

[Scomage]

I don't see any steps in your answer as mentioned in the last sentence.

[Sheraz.Salim]

Here from ASDM check Configuration > Firewall > NAT Rules, Ensure there is a NAT exemption rule for traffic between the local and remote subnets.

to check the access-list 

Configuration > Firewall > Access Rules: Ensure there are rules permitting traffic between the local and remote VPN subnets, and that they are above any "deny all" rules.

VPN crypto-map  Configuration > Site-to-Site VPN > Connection Profiles and Advanced > Crypto Map Entry: Ensure the local and remote networks match what is configured on the SonicWall.

The information you can collect from ASDM

NAT Rules: Screenshot or export of all NAT rules, especially those involving the VPN subnets.

Access-Lists: Export the access-list/s used for the VPN and the global access rules.

VPN Monitor: Go to Monitoring > VPN > VPN Statistics > Sessions; check bytes sent/received for the tunnel.

Packet Tracer Output: Use the Packet Tracer tool in ASDM (Tools > Packet Tracer) to simulate traffic from the local subnet to the remote subnet. This will show if traffic is allowed and through which rules it passes.

Real-Time Log Viewer: Go to Monitoring > Logging > Real-Time Log Viewer. Set log level to "Informational" or higher to capture VPN and NAT events.

[Scomage]

See the screen shots in the attached word doc. I suspect there may be conflicting Crypto maps.  There appears to be multiples for the same vpn.  We should have three vpns as shown on page 3 of the document. They all need to connect to 10.10.30.0/24.  The 2 from 192.168.10.0/24 and 192.168.1.0/24 work correctly.  The failing one is 192.168.43.0/24.

Please advise if I should delete some of the extra crypto maps.

[Sheraz.Salim]

Thanks for the information. I understand you're not very familiar with the CLI, but based on what you've shared, it looks like we'll need to access the CLI and run some commands. As part of this, we'll also need to capture packets to help identify the root cause and location of the issue.

Here are the commands you need to run. Please sanitize any sensitive or irrelevant information before sharing the output:

show nat
show run nat
show access-list
show group-policy 1.1.1.1 (replace 1.1.1.1 with your actual remote peer IP address)
Run a packet-tracer for the relevant traffic and provide the output
show crypto isakmp sa detail
show crypto ikev2 sa detail

last command show tunnel-group 1.1.1.1

[Scomage]

See the attached output.  show tunnel-group and show group-policy returned an error.  I did not know how to create the packet tracer. Perhaps you can give me a little instruction based on the output I got.  

[Aref Alsouqi]

Which one is the 192.168.43.0/24 on page 3 in the doc you shared? is it the one with the public IP you highlighted that is finishing with .21? if so, what is inside the "MWF_Office_Lan" object? is the subnet 192.168.43.0/24 added in there?

Also, in the first screenshot that is showing the NAT exemption rules, you have rule number 1 with the destination subnet 192.168.43.0/24 and you also have rule number 5 with the same destination, however, rule number 5 is configured with the source subnet 10.10.30.0/24. Am I right in assuming that this one is the one that should match your crypto traffic? if so, I believe the source interface selected on that rule is wrong and it should be VLAN30 rather than inside?

[Aref Alsouqi]

When data is not transferred it would sugget an issue with the crypto access list or the NAT rules as already suggested. Each site-to-site VPN tunnel will have its own set of variables. For instance, tunnel 1 goes to site 1 where the remote sunbet is x, and tunnel 2 goes to site 2 where the remote subnet is y. If you copy the settings from tunnel 1 they won't work with tunnel 2 because the remote subnets will be different for each remote site. So in that case not the crypto access list nor the NAT exemption rule will match the VPN traffic and as a result the traffic will not be sent over the VPN tunnel.

The fact that Sonicwall shows connected could suggest that phase 1 is up but not phase 2. Not sure how to check phase 2 on Sonicwall as I have no experience with it. If phase 2 is down then this would suggest there are mismatched values between the Cisco and Sonicwall devices. If phase 2 is up and still no traffic then probably the issue is caused by NAT and the VPN traffic is not exempted.

[paulwelchh]

Since the SonicWall shows a connection but isn’t passing data, check the VPN configuration to ensure the IKE and IPsec settings match on both devices. Look at the Cisco ASA logs for any dropped packets and verify that the access lists allow the necessary traffic, and check your NAT settings to make sure they’re not altering the VPN traffic.