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

HI Team,

We have a site-to-site tunnel between our headquarters and a remotes site. The remote site uses AT&T DSL and we have assigned static IPs addresses from the provider that we have assigned to our remote firewall.

When setting up the VPN tunnel, if using ESP/3DES as the Phase 2 security parameter, we get the signal from both sides of the tunnel that the connection is successful. However, when we try to pass traffic, nothing appears to be passing from the local firewall to the remote network. (basic ping's fail any response)

From the network monitor, the PING packets are "Received", by the local firewall but are not passed through to any other interface (no references to forwarded, consumed packets by the firewall etc) and seem to simply die at the firewall with no outgoing interface.

When the Phase 2 security is changed to AH (as I understand not ideal for security) the ping traffic passes through the firewall appropriately and gets responses from the remote network via the VPN site-to-site.

When changes back to the more secure form, the traffic stops again.

Any help or suggestions would be appreciated!

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
JohnBusiness Consultant (Owner)Commented:
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.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
DES is a no-go for site-2-site. But AH is worse - no encryption!
Check Out How Miercom Evaluates Wi-Fi Security!

It's not just about Wi-Fi connectivity anymore. A wireless security breach can cost your business large amounts of time, trouble, and expense. Plus, hear first-hand from Miercom on how WatchGuard's Wi-Fi security stacks up against the competition plus a LIVE demo!

RatherBeinTahoeAuthor Commented:
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.
JohnBusiness Consultant (Owner)Commented:
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.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
JohnBusiness Consultant (Owner)Commented:
I always turn PFS off on my tunnels and keep phases the same.
JohnBusiness Consultant (Owner)Commented:
@RatherBeinTahoe  - Any update on using the same settings for both phases? You can always change afterward once you get the connection working.
RatherBeinTahoeAuthor Commented:
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).
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
RatherBeinTahoeAuthor Commented:
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.
JohnBusiness Consultant (Owner)Commented:
Qlemo wrote: "There is no obvious reason it does not work."

RatherBeinTahoe wrote: "I tried different combinations of Phase1 and Phase2 and they all connected appropriately according to the logs on both sides and the connection status"

So you are using the connection parameters as we discussed and ensuring properly mirrored at both ends, I have 4 site-to-site tunnels with very similar parameters and they run non-stop with no issues.

Have you tried updating firmware on the SonicWalls? Is there a lot of setup?  You might take one end, do a factory reset, update the firmware and test and then do the same thing at the other end.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Didn't see the tag "SonicWall" yet, but now I can get more specific with my advice. From your screenshots I take it you are using SonicWalls on all sites.

I cross-checked with our SonicWall counterparts (we don't use SonicWall), and have no issues with 3DES or AES 192 with SHA-1 and DH-2, with or without PFS.
Again, the issue is most probably on the Firewall part, not the VPN connection itself. Though what you wrote in http:#a40679228 looks correct and complete, that's what you have to look at. The "NonWorkingTunnel.." output is what I would expect with a running VPN, at least for the "x is located on the VPN" part.

Is it the same on both sites, no matter which one initiates traffic?
RatherBeinTahoeAuthor Commented:
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?

JohnBusiness Consultant (Owner)Commented:
I asked earlier if you tried firmware updates and factory reset and set up again. Did you try ?
RatherBeinTahoeAuthor Commented:
Thanks everyone for your assistance. I believe we found a solution:

The gateway device that AT&T had given us to set-up our remote site had additional firewall rules applying that appear to have blocked the ESP traffic between the VPN devices. It's very confusing to me, that although the statics were assigned, and it appeared that nothing should have been interfering with the traffic - mainly do to the successful connections of PHASE1 and PHASE2 of the VPN - there was an additional check box further disabling internal firewall rules.

I've included images highlighting the change I made (the static info has to be configured on the device - either AT&T or I did this prior) and then the prior settings are the same as they've been throughout troubleshooting. Again, highlighted item is the one I changed. I've included a copy of our remote site AT&T device information for future reference.

Sonicwall support did lean on the ISP as being the cause of the problem. Given what I was interpreting, it sounded like an issue outside of our network, and they confirmed that thought.

Thanks everyone for your input. I appreciate your help!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RatherBeinTahoeAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.