Sonicwall to Cisco VPN with NAT/PAT

Hello Experts,
I am attempting to configure a VPN tunnel between our Sonicwal TZ 210 (SonicOS and a customer's Cisco 3000 device.

Goal  -  to configure our subnet ( to access (which has been translated on the customer's side to get us to the privately routed public IP address of the server we need) via a VPN connectoin, while appearing on their network as   The customer has suggested that we use PAT to route all of our traffic through so that we route through their networks appropriately.

The good news - the tunnel works (Key exchanges work according to logs on both ends and both ends show a working tunnel)

The bad news - I can't get my traffic to route properly to this VPN.

The ugly news...

Why? - well this is not a "normal" VPN setup.   The customer has NATted the VPN on their end in order to provide me with Access to only the one server that we need access to.   This seems to have been set up OK - we have tested this by pinging a NATted server on their network from mine.  

To further complicate things, the server we need to reach is not on the customer's network, but is actually a vendor's system on a public IP that is only accessible from the customer's network.   This means that I need to use NAT/PAT on my end expose all of the traffic from my local subnet as a single IP address that was provided by the customer (that will route properly on their network)

Sonicwall provides a pretty good walkthrough of this, which has gotten me most of the way at

Here is my current VPN policy setup (skipping the IKE/IPSEC info - since this is working fine)...
Policy Type - Site to Site

Local Networks - Choose local network from list - LAN primary subnet (this is my local subnet)

Remote Netowrks - Choose Destination network from list - Customer - Remote (this is a single address "network" provided by customer, and is a public-range IP address that has been reserved for this purpose - it is configured (as per above document) in the VPN zone, Type of Network with an address with a netmask of

Enable Keep Alive - Checked
Apply NAT policies - Checked

Translated Local Network - Customer - Local (this is a similar single address "network" provided by customer) - configured in the LAN zone, as a type Network, with an address of and a netmask of

Current behavior - the tunnel comes up, but only when i turn Keep-Alives ON.   Otherwise the tunnel does not come up, even when pinging the desired server  In fact, when looking at a Sonicwall Packet Capture, the ICMP traffic of a PING normally shows "forwarded", where pings to this address just show "recieved" - leading me to believe this is a routing problem related to my configuration.  

Anyone have any ideas?

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.

The only reason you would need to NAT is if your LAN IP network matched the LAN IP network of the other end of the VPN.  They shouldn't have to NAT on their end at all.  They only need to create the proper firewall rules to allow or disallow access to areas of their network.

Am I understanding properly?
pmartinjr1Author Commented:
The customer is  NATting primarily because the endpoint that we are trying to reach is a privately routed IP address in the public IP range - it is provided by one of our customer's vendors and is only accessible from inside the customer's network.    In order for our traffic to route properly, the customer's vendor must see our traffic as part of the customer's network.    (and also because of overlapping private IP address ranges between our networks)

Just to confirm - we have an active VPN tunnel, which connects to the network, which is also the address of server we want to access.   This portion has been tested and confirmed to function properly.   However, I need to present all VPN traffic from my local subnet to that server as coming from in order for it to route over the customer and the customer's vendors networks properly (which sounds like a job for PAT!)

OK...I understand.  What I have found easier than relying on the wizards when setting up the firewall and NAT rules, is to setup the VPN first then manually setup the rules.  When you setup the VPN, set the local as the IP you want to present yourself as to the remote end.  Setup the firewall rules as the IP you want to present yourself as to the remote site.  Setup a NAT rule to NAT your local traffic as the IP you want to present yourself as.  Use the concepts presented by the SW KB article you have presented in this question, but setup the rules manually.  Does that make sense.  I can provide more information if you need it.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

pmartinjr1Author Commented:

Thank you for your continued assistance.  I agree.   I did not use a wizard, but did keep the "apply NAT policies" checkbox checked - because without this, the VPN attempts to connect by presenting my local network - which fails the tunnel.  Also, I did not check the "suppress automatic access rules" checkbox.   However, in this case, the rules are exaclty what I would have set up!  here is my complete config.

Does anything look amiss?
What your VPN settings are indicating is traffic that finally will traverse the VPN will have an IP address of your LAN Primary Subnet.  The VPN tunnel is coming up because the other end of the tunnel is expecting traffic with IP addresses of your LAN Primary Subnet.  However, you are nat'ing IP addresses from your LAN Primary Subnet BEFORE they are to go across the VPN to  No good.  When the traffic hits the VPN, it says your IP address doesn't match the LAN Primary Subnet, so I'm not going to let you across.  As part of their VPN rules, if they were expecting traffic from your end of, then the tunnel wouldn't come up.

First, disable the Apply NAT Policies under the Advanced tab and try a ping or whatever.  If they are expecting an IP address from your LAN Primary Subnet (and they are based on the fact that the tunnel being established), then they must be doing the NAT'ing for you.  I'm guessing that it will be successful.

Second, if they are not doing the NAT'ing for you, then the VPN tunnels need to be reconfigured.  You'll want them to change their Destination to  On your end, you'll want to change the Local Networks under the Network tab from LAN Primary Subnet to Hershy - Local.  Leave your Apply NAT Policies enabled under the Advanced tab.  You may have to disable and re-enable the VPN policy.

Let me know your thoughts.
pmartinjr1Author Commented:
I am not sure that your assessment in the first paragraph is correct - or perhaps I am not understanding you.  

The following is logged ...

IKE Initiator: Accepting IPSec proposal (Phase 2)
VPN Policy: Penn State Hershey; Local network /; Remote network

This indicates to me that the VPN is being established based on our network presenting and their network presenting    In other words - they are note expecting our local subnet.

We are, in fact, attempting to NAT before our traffic goes through the VPN.    This is exactly what we are trying to do!   More precisely  - perhaps - we would like to use PAT to make all traffic that we route to their network appear to be from

I did try what you suggested...
1) I disabled the NAT policies for this VPN - still no ping.
2) Assuming that they have set up their VPN correctly, I did change the LocalNetworks tab from "LAN primary subnet" to "Hershey - Local" - with NAT Policies enabled.   no ping.

Your second suggest is closer to what we are trying to achive - we are doing NAT/PAT on our end.   However, based on what I see above, I think they are configured correctly for this scenario.

Would you agree.   Any suggestions?

Thank you!

I had a client site where several different subnets were being passed across the VPN.  Primarily was the subnet which was used on both ends.  Working with Sonicwall, we created a VPN and disabled all the automated firewall and NAT rule creation.  For the Local networks, I configured a group that contained other local networks but also the "local_hide" for  The Destination network was a group that contained the "remote_hide" network in addition to networks on the remote end we needed access to.  The firewall rules used the local network and desktination network groups specified on the network tab of the VPN.  I manually created the NAT and firewall rules.  I only nat'ed the > for local and > for remote.  The other IP addresses were kept, basically, weren't NAT'd.

If I configured your sonicwall, I would do so as the described document.


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
pmartinjr1Author Commented:

Wow!  That was a very thorough explanation and an exceptional walkthrough.  You have obviously spent some time on this  - THANK YOU!

I have followed the steps in your document.

PING is still not working, but I am getting HTTP!   I am not sure if I have the right URL to test on the destination server, (to make sure I am getting to the right place) but things are looking good.  

I will get more info from the other side tomrrow and update the issue.

You have no idea and you're welcome!  They may be only allowing certain ports like HTTP which would explain why you're not getting a response from ICMP traffic.  Let me know.
pmartinjr1Author Commented:
I would award digitap 5000 points if possible - I could not have possibly asked for a more complete, well thought out, and documented solution.  
Glad I could help and thanks for the points...even if it's not 5000!
pmartinjr1Author Commented:
Final comment -

The solution works perfectly, however please note that PING was not working.  The customer swears that they are not blocking ICMP.   I beliieve them because my Sonicwall logs show the ICMP packets to the destination as "received" and not "Forwarded".   Also - the HTTP packets show as "Consumed" instead of forwarded.   It sounds like there might be something within the Sonicwall that is absorbing, or at least not routing ICMP packets.

yes, that does seem to be the case. i assume within the firewall rules you allowed any traffic ingress and egress, right?
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.