Old Sonicwall ok, New Sonicwall not.

Hi pdesjardins1,

Port forwarding is vey straightforward but you need all of the right pieces setup correctly. The SonicWALL wizard (select public server) is the most complete way to  achieve this. You need the right Acess Rules, NAT Policies, Address Objects & Services. Once you have them correct, the only question left, on the networking side, is if port translation is required... basically is the server setup to listen on port 60004? If so, then nothing more is required on the networking side, which means you need to look at the server's firewall & IIS config. If, however, the server is not listening on port 60004, then you will need to translate the port in the NAT Policies from 60004 to whatever it is listening on, e.g. port 80 or 443, etc.

By the way, port obfuscation is not security. Open ports are open ports, protocols used, and packets running through them are easily identifiable unless encryption is used.

Let me know if you have any questions!

Thank you for replying.
I used the SonicWall wizard for setting up this service.
I know the source of the traffic, WAN
I know the target IP, xxx.xxx.xxx.210
I know the port 60004
I know the internal server zzz.zzz.zzz.103

I think I might just wipe it out and start again.

But is the server listening on port 60004 or not? if it is not then you will need to port translate to resolve. Most people that setup random port numbers typically do not do so on the server as well, in which case the port requires translation from the exterior port # to the interior port #.

Make sense?

Hello.
The server is listening on 60004.
I used Portqry inside and outside my firewall. Both attempts returned LISTENING. Which means traffic went to the server and back.

Someone had to have modified something as I said Port Forwarding is very straightforward.

• Is the server is in the LAN, if not which Zone?
• Any VLANs involved?
• Is there any routing downstream from the firewall?

Post screenshots of your NAT Policies & Access Rules.

The server is in the LAN
The LAN does have VLANS
There is routing downstream of the firewall. The LAN side of the Firewall is 10.x.0.1. The server is 10.x.3.103
Firewall can ping the server, server can ping the firewall. Port query from inside and outside the firewall show the server is "LISTENING"

NATpolicies.jpg
AccessRules.jpg

I don't believe it is a firewall or network-related problem. That error message is coming directly from the web server (it actually indicates the directory having the problem and says the target server is actively refusing it). You would not get this message from the server otherwise. It appears to be talking to the web server OK but I'd inspect the web server to source the problem. Look at its Stack Trace.

As Blue pointed out, the error should have absolutely nothing to do with the Sonicwall.

However, given what you've spelled out (swapping in the old Sonicwall gets things working) means that there should be a difference in configuration.

So I'll ask 2 questions:
1) Do you have a proxy?
2) How did you get the configuration from the old Sonicwall to the new one? If you went the import route and you're having issues, have you tried resetting the new Sonicwall to factory settings, upgrading to the latest SonicOS, and building the configuration from scratch (not import)?

The problem was with the NAT policies. (please see NATpolices.jpg)
The SonicWall wizard listed the 'Original Source' as "Firewalled Subnets" However, to SonicWall, this was only the subnet on which the SonicWall box resides. The webserver box resides on a different subnet.
In the communication, packets can flow in and out, Internet to webserver/webserver to internet, just fine. But at some point the webserver tries to send, and the Firewalled Subnet NAT policy kills it.
Changing the policy to read 'all LAN Subnets' fixed this issue.

The SonicWall wizard listed the 'Original Source' as "Firewalled Subnets" However, to SonicWall, this was only the subnet on which the SonicWall box resides.

It sounds like someone tried to modify things they shouldn't. The Firewalled Subnets object is system created and literally covers LAN subnets and every other internal Zone within the Firewall including the DMZ. It is the correct way of creating a Loopback policy. A Loopback policy is used when internal users try to go to say the web services hosted internally and use the Public IP address opposed to the Private IP address the connection will work. Without this policy doing so would fail.

The 2nd and 3rd policy in your image are your Inbound and Outbound policies respectively.

All LAN Subnets (LAN Subnets is though) is not a system created object so did you create this one yourself? Even if you change the Loopback policy all it does is restrict the ability for loopbacking to take place from any internal Zone to only the LAN Zone.

I do not see how this fixed anything unless there was some other misconfiguration. So are you saying when you hover over the Firewalled Subnets object it shows the X1 IP address?

When I hover over Firewalled Subnets it shows '10.x.0.0/255.255.255.0'
The webserver is 10.x.3.103
I changed the loopback to read '10.x.0.0/255.255.252.0'

OK, so something in your network config is not right. 10.x.0.0/255.255.255.0 is 10.x.0.0/24. Where is your 10.x.3.0/24 subnet?

If you have say 3 internal subnets 10.x.0.0/24, 10.x.3.0/24, and 10.x.10.0/24 then all 3 should show when you hover over Firewalled Subnets. So maybe there is a misconfiguration of your subnet like incorrect Mask Bits...for example if 10.x.0.0/24 is supposed to include the range all the way through 10.x.3.0 then a /24 would be incorrect. You'd actually need the network to be configured as such 10.x.0.0/22 to include the total range from 10.x.0.1-10.x.3.254. If that is the case it would make sense what you are describing as your solution provided that you only have essentially 1 internal subnet because with a misconfigured subnet SonicWALL would accurately read Firewalled Subnets as 10.x.0.0/24, which completely excludes your server's subnet of 10.x.3.0/24; therefore when you change the loopback to manually include the subnet it works. Make sense?

So how many subnets are you supposed to have and does the SonicWALL accurately represent them?

I should have 4 subnets.
10.x.0.0
10.x.1.0
10.x.2.0
10.x.3.0
255.255.252.0 (or /22)

Does my SonicWall accurately represent them?  I don't know. I have them as Address Objects and they are in Routing. Traffic routes properly.

Ok, so is each subnet then a /22? so its like this:
10.x.0.0/22
10.x.1.0/22
10.x.2.0/22
10.x.3.0/22

I have them as Address Objects and they are in Routing. Traffic routes properly.

It appears you have not configured any of them in the Interfaces except the 10.x.0.0/22 but it is actually misconfigured as a /24, hence it showing as a '10.x.0.0/255.255.255.0'. If your network topology is a Collapsed Core then you should configure all these networks in the Interfaces as Sub-Interfaces under X0 so SonicWALL knows about them. This will automate a ton of networking which will not need to be done in a manual fashion plus it corrects networking problems/issues and anomalies. For example, once the SonicWALL is properly configured from a networking standpoint things like this NAT Loopback policy would not have been an issue nor would you need to create custom/manual routers. If you can screenshot your Interfaces and Zones pages that will clear up a lot.

ok. I'm with you.
The SonicWall has the routes for the other address, but does not know they are trusted.

Don't think Sub-Interfaces is for me.
My SonicWall connects (LAN side) to a Layer 3 switch. The switch does all the routing.
I need another way to tell the SonicWall that the other subnets are to be trusted.