We help IT Professionals succeed at work.

Sonicwall One-to-One NAT problem

Rick Mills
Rick Mills asked
on
My client has a Sonicwall TZ 180 Wireless running Standard OS.  They wanted to host their own website, so I setup the web server with a static IP.  I then configured One-to-One NAT on the Sonicwall, using the 2nd of two IP addresses provided by Cox.  All worked beautifully and has been working for 3 months.
Last night, one of the employees went into the office when they realized the web server was not available and found the web server apparently installed some updates and restarted itself.  It was configured for DHCP and no longer had a static IP.  He configured it for the same static IP.
I can remote into the web server.
I can remote into the SBS server and access the website by entering http://webserver.
I cannot browse the Internet from the web server.
If I ping www.google.com from the web server, it resolves to the correct IP, but I receive request timed out messages.
I found that if I disable One-to-Onet NAT on the Sonicwall, I can browse the Internet from the web server.  

As far as I am aware, nothing on the Sonicwall changed.  I don't believe anyone had the password to make any changes.  The web server restarted and was configured with DHCP, so obviously there were some definite changes there.  Disabling One-to-One NAT and being able to browse from the web server and being able to access the website from the LAN certainly make it appear as if the Sonicwall is blocking (or not properly routing) HTTP traffic to the web server.

Does anyone have any suggestions on how to go about troubleshooting this issue?
Comment
Watch Question

Top Expert 2010
Commented:
When they reset the static IP, did they use the same one they had before?  Also, setting the static IP, you have to set the other configuration settings, so do they have the correct gateway and subnet mask?  Did you try deleting and recreating the NAT rule?
Steve AgnewSr. Systems Engineer
Commented:
The one to one nat routes traffice to the different IP and your routing in the sonicwall probably isn't right.. you do know there is a public server wizard in the sonicwall?  If you go through and delete all the firewall rules, custom NAT for the webserver, and address objects, I think you have to do it in that order, you can just use the public server wizard to set it up to work correctly and then your webserver can use the default routing for internet access in the sonicwall and it's main interface IP.. you would only need one to one NAT if you are doing more than just HTTP HTTPS (and you don't want to enable things you aren't using do you?)  A 1 to 1 NAT on your sonicwall with the wrong firewall rules exposes everything to the internet instead of just the HTTP and HTTPS and why expose it if you aren't using it?  That just makes it less secure...  If you want terminal services to it, after you run the public wizard just add Terminal Services to the service group under firewall that the wizard makes.
Steve AgnewSr. Systems Engineer
Commented:
Oh google doesn't return pings and more and more websites don't it lowers the hack attacks on them as most hacker programs ignore IP's that don't return a ping..

If you want to see internet connectivity and how it's working to a tracert

tracert www.google.com

then you can see if you get past the sonicwall...

My guess is they configured the default gateway wrong making it available locally but not able to get through the router.
Rick MillsPresident

Author

Commented:
Turns out it was a problem with the ISP.  I'll share the poins evenly with those who responded.
Top Expert 2010

Commented:
What did the ISP resolve on their end to fix the issue?  The information would be helpful for those who are searching for a solution to this issue.

Thanks for the points!
Rick MillsPresident

Author

Commented:
I'm not exactly sure.  It is Cox Cable and we have 2 public IP addresses from them.  The primary IP, which provides general Internet access for the office and remote access to PCs, was working fine.  The 2nd IP was dedicated to a webserver.  It was only the webserver that had the problem.  We realized that if we obtained an IP address from the DHCP server (which uses the primary IP for Internet access), the webserver could communicate fine.  Of course, no one could reach the webserver from the outside, as the firewall's routing was set for a specific IP.  If we manually set the IP address and used the secondary public IP as the default gateway, it would not communicate.
My client contacted Cox and the tech said there was a problem with the routing on the secondary IP.  Once they fixed it, all worked well.
Top Expert 2010

Commented:
That's great information.  Thanks for taking the time to provide the information...