Sonicwall to Cisco VPN with NAT/PAT

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

Goal  -  to configure our subnet (192.168.249.0/24) to access 150.xxx.xxx.68 (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 150.xxx.xxx.69.   The customer has suggested that we use PAT to route all of our traffic through 150.xxx.xxx.69 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

http://www.sonicwall.com/downloads/NAT_over_VPN_with_SonicOS_Enhanced.pdf

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 150.xxx.xxx.68. with a netmask of 255.255.255.255.

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 150.xxx.xxx.69 and a netmask of 255.255.255.255

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 150.xxx.xxx.68.  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?



pmartinjr1Asked:
Who is Participating?
 
digitapCommented:
I had a client site where several different subnets were being passed across the VPN.  Primarily was the 192.168.1.0/24 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 192.168.1.0/24.  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 192.168.1.0/24 > 192.168.98.0/24 for local and 192.168.1.0/24 > 192.168.98.0/24 for remote.  The other IP addresses were kept original...so, basically, weren't NAT'd.

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


Thoughts?
hershey-vpn.pdf
0
 
digitapCommented:
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?
0
 
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 150.xxx.xxx.68/32, 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 192.168.249.0/24 to that server as coming from 150.xxx.xxx.69 in order for it to route over the customer and the customer's vendors networks properly (which sounds like a job for PAT!)




0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
digitapCommented:
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.
0
 
pmartinjr1Author Commented:
Digtap,

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?
VPN-General.png
VPN-Network.png
VPN-Proposals.png
VPN-Advanced.png
Hershey-Local-Address-Config.png
Hershey-Remote-Address-Config.png
NAT-Policy---Inbound-Traffic.png
NAT-Policy---Outbound-Traffic.png
Firewall-Rule---LAN-to-VPN.png
Firewall-Rule---VPN-to-LAN.png
0
 
digitapCommented:
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 150.231.5.69.  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 150.231.5.69, 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 150.231.5.69.  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.
0
 
pmartinjr1Author Commented:
Digitap,
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 150.231.5.69 / 255.255.255.255; Remote network 150.231.5.68/255.255.255.255

This indicates to me that the VPN is being established based on our network presenting 150.231.5.69 and their network presenting 150.231.5.68.    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 150.231.5.69.

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!

Paul
0
 
pmartinjr1Author Commented:
Digitap,

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.

Thanks!
0
 
digitapCommented:
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.
0
 
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.  
Kudos!
Paul
0
 
digitapCommented:
Glad I could help and thanks for the points...even if it's not 5000!
0
 
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.

0
 
digitapCommented:
yes, that does seem to be the case. i assume within the firewall rules you allowed any traffic ingress and egress, right?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.