My VPN Tunnel will not pass traffic when ESP/3DES is enabled, only EH, in Phase 2 Proposal?

Check if the Diffie-Hellman settings are correct, too. AH does not use DH.
And if available, you should use AES. More secure, needs less resources.

Check again to make sure each Phase is exactly mirrored on the other end.

Also, make sure your hardware VPN is fast enough to use 3DES. Try DES and see if that works.

DES is a no-go for site-2-site. But AH is worse - no encryption!

Hi All, thanks for your input. I've included a copy of my settings that work. And then a copy of the settings that don't. As I said earlier, the ESP/3DES, connection says its active (on both sides) with a successful connection made between both sites in the site-to-site but no traffic will pass through.

When using AH, the traffic will pass through the site-to-site. Not sure what is the problem or what is preventing ESP/3DES from working appropriately. I have other tunnels using the same protocols and they are working fine.

Any other ideas? Noted that "AH" is not appropriate just using it as a testing tool.
CaptureVPNSettings.JPG
CaptureVPNSettings-NotWorking.JPG

I think for Phase 2 you need Group 2 DH, and 3DES as you also have in Phase 1. All my tunnels have the Phases the same. Try that and let us know. In your non-working setup use DH Group 2 instead of ESP. Try these and let us know.

There is no obvious reason it does not work. You'll need some debugging on the firewall/router, otherwise you'll probably never find out.
What we cannot see is the associated networks. Some firewalls take the negotiated network settings (= local network, remote network, ports to open) to generate firewall rules allowing the corresponding traffic. On a S2S VPN those should be set to the actual networks used on each side. and no port restriction ("any").
I didn't look it up, but AH might not use that info, while ESP might. AH does not protect, only make sure the packets are from the other side, and not injected.

John, PFS is always optional. P1 and P2 settings are not related, but usually set the same. Though, there are VPN devices which do not allow to set up different parameters for both phases with exception of PFS.

I always turn PFS off on my tunnels and keep phases the same.

@RatherBeinTahoe  - Any update on using the same settings for both phases? You can always change afterward once you get the connection working.

Thanks everyone for your help.

@John Hurst I tried different combinations of Phase1 and Phase2 and they all connected appropriately according to the logs on both sides and the connection status. Regardless, not ping packets or any other traffic was flowing.

I checked the Firewall rules for the network segments and they were set-up "auto-added" as follows: LAN to VPN Zone, Allow Any, Main Subnet to Remote Subnet. VPN to LAN Zone, Allow Any, Remote Subnet to Main Subnet. The same is configured on both sides.

I've included an image of the logs for the VPN tunnel creation and then another of the packet information for a diagnostic ping from the Remote Firewall to the Main firewall. The traffic just seems to stop at the local firewalls (same on both sides).
LogVPNCreation.jpg
PacketMonitorPingSitetoSite.jpg

You do not see anything corresponding on the Main firewall when pinging from Remote?
Also try something different from ICMP. I don't think it makes a difference, though.

Thanks for your assistance.

I can see management traffic from my end (HTTPS) and the remote router but none of it appears to be passing through the VPN tunnel. The interface isn't available to communicate over VPN going along with the associated problem. There is a find network path function on the remote firewalls and I found some interesting results but I'm not sure if its relevant:

I'll include the images below: I tested a working remote site that says the Main site interface is available through the X1 (wan) interface on the Firewall and returns information about the hardware it passes through. The non-working interface doesn't reference the X1 (wan) port but references the VPN interface instead, while stating there is no hardware between the sites.

I've always had success, either manually creating these tunnels, or using the wizard. I'm not sure what difference is between these two sites but I assume this is a step in the right direction.
WorkingTunnel-VPN-Example1.jpg
NonWorkingTunnel-VPN-Example2.JPG

Thanks everyone for your input.

As stated before, the "green" up box is lit on both ends of the site-to-site tunnel and it looks as though its connected properly. The network settings look appropriate on the firewall side concerning communication between the LAN networks. When setting PHASE 2 to the less secure AH setting, the traffic will flow and I can ping the interfaces on the LAN from both sides. So I opened a ticket with Sonicwall/Dell support and we did some further testing:

When "ESP" is set as a packet monitoring filter on the MAIN site without regard to which remote host we're trying to talk to (basically all VPN talking to the MAIN site) I can see lots of "FORWARDED, CONSUMED, GENERATED" messages regarding the other site-to-site tunnels and corresponding IP addresses.

When "ESP" is set as a packet monitoring filter on the MAIN site and the same filter applied on the REMOTE site, the traffic generated simply states "FORWARDED, GENERATED" but never any reference to "CONSUMED" nor does the Source IP ever correspond to the remote site (in either direction). Both devices are attempting to send out ESP packets but never seem to receive any content from the remote-sites.

Sonicwall support suggested I contact the ISP to discuss if something is being blocked. Knowing full well, the ISP will most likely blame our configuration ("We don't support anything beyond our devices." etc). The support tech suggested that the firmware revisions may be far enough apart to cause issues but that the logs should state that some traffic was being received from the remote site, regardless.

Any further suggestions or notes for how to handle the discussion with the ISP?

Thanks

I asked earlier if you tried firmware updates and factory reset and set up again. Did you try ?

With the help of the forum group, we ruled out obvious items. With the help of vendor support for our firewall we determined that ESP traffic was not passing correctly (checking logging) and determined it was ISP related. I double checked the settings I had control over on the ISP gateway device and was able to find the setting to disable the firewall rule preventing traffic from passing.