Link to home
Start Free TrialLog in
Avatar of MaxDes101

asked on

Sonciwall tz-210 open ports 60000-60100 to connect to EXTERNAL FTP SERVER PASSIVE

I was asked by a client to connect to their FTP server. I was told I need to open ports in MY firewall to connect to THEIR ftp server since it uses passive ftp.

Firstly this sounds wrong to me, but I learn new things everyday so who knows.

Secondly how do I accomplish this using the Sonicwall tz-210 I am behind right now. I am the admin so I can make conf changes.

Could someone enlighten me and walk me through this?

Avatar of digitap
Flag of United States of America image

Here is a KB on how to open the ports.  if you are concerned about the security aspect of opening up these ports, confirm with them, the public IP addresses they'll be using.  change the WAN > LAN firewall rule for the source from Any to their public IP address.  this way ONLY their FTP server will be allowed in through your firewall to your internal client.

regarding ftp and why the ports need opened, there can be issues with active FTP in the two-way communication that is established between the client and server.  using passive typically resolves that, however if they are using non-standard ports, then you may need to open up your firewall for them.

Avatar of MaxDes101


So can you help explain what I need to enter into the  NAT portion? Can I just have it allow any LAN subnet to access the external FTP server? I have included the picture of what I am seeing. User generated image
Avatar of digitap
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I have tried both ways but to be clear when you said:

"then, go to network > address objects and create a new address object representing the public IP address.  make it a host and on the WAN zone."

You mean the public IP of the server I'm connecting to or my own public IP for the firewall/
you want to use the public IP address of their ftp server.  you could create a firewall rule to allow Any as the source just to make sure everything works.  however, if you wanted to lock things down more securely, you could change the source of the WAN > LAN firewall rule to their FTP server's public IP address.

it's possible there may be more than one public IP address.  if they have some "round robin" configuration where you use a URL instead of a public IP to connect to their FTP server, then you'd need to get the list of public IP addresses they'll use, create an address object for each one and add them to an address group.  you'd then use this as the source in your WAN > LAN firewall rule.
You've been great.
Pretty sure I have everything as you said it was supposed to be, but I'm still timing out on their server.

They do provide public IPs to connect to and I tried it as both a range and a host with no luck.

All I get is a time-out.


ok...let's look at the log on the firewall.  go to Log > Categories.  make sure log level is debug.  then, you'll see a bunch of categories that you can select.  if you check the box at the top of each column, you select the categories for the whole column.  you want to select everything.  go back to your log and initiate an FTP session.  see anything?

also, you might make sure the sonicwall isn't blocking FTP access.  go to security services > Gateway AV.  remove the check box for FTP and save the settings.  try another session.
something to consider, the instructions indicate making a NAT rule to the host on the LAN subnet.  without a reciprical NAT policy, we may not be getting good NAT mapping.  if the suggestions above fail, you might try creating a new address object representing the host on the LAN subnet.  then, go to your NAT policy and change the Translated Destination to the new address object.

make the new object a host and on the LAN zone.
TCP handshake violation detected; TCP connection dropped
And now I get no other log messages when I attempt a connection. Have tried the other NAT solution and still no luck. I'm starting to wonder if their server/firewall isn't configured correctly....
i can't think of anything else without seeing your setup on the sonicwall...i'll have to think some more.
hhhmmm dang. and due to hipaa regulations I cannot have you log in or anything. Thanks for your help.
let's have a look at the monitor.  system > packet capture.  you'll want to configure a capture for the X1 interface and the source IP be your private IP.  make sure the check box for port matching is checked.

start another ftp session.  see if anything is dropped.
Not seeing anything at all. tried with and without dest IP. added pic for my settings. User generated image
ok...try leaving out the source ports and IP types.
But I am seeing on the x0 interface that my traffic gets forwarded to that address.  
X0      outsideIPhere     IP       TCP      20422,21    forwarded
so, it's going out as port 21...hmmm
then, let's change things and remove the source IP.  we're looking for dropped packets.  then, we need to confirm if the ports they designated are the correct ports to begin with.  on your FTP client, have you had to specify that you want to use Passive FTP?
yes. passive is selected in Filezilla.

ok with source IP gone I see:

my router pub IP   destination server IP    IP  TCP    35946,21  Forwarded.
in passive FTP it still uses the initial port 21 for connections right? So if it doesn't get a comand port connection on 21 I would never be able to connect to the remote server....

Does that even sound logical? heh.
with just the X1 interface monitored, you should see something coming back from them.  if there was traffic being returned, you'd see it being dropped in the monitor @ the X1 interface.  i take it you aren't seeing that, right?
his is what I received from their IT people about my connection.....

Command port is 21
Data ports are 60000-60100 (for passive ftp)

Not seeing anything coming back from them at all.... in fact I ended up doing a stealth scan earlier just to verify there was in fact something on that IP address.
what if you tried using explorer to access the ftp site?  what happens?
as such:


if that's the correct syntax then it just times out like filezilla.
there has to be something going on with their end.  without any of the configuration settings you have on your sonicwall, my packet monitoring gives me the same thing.  i see the initial port 21 as passive ftp does then i see the random port initiated by the ftp client.  however, i don't see the response from the server.  now, something that i don't understand, the client is supposed to initiate the ports to the server and i don't see those ports being initiated within the range specified....60000 - 60100.

something's wrong.
I don't even see where you COULD specify the passive port range. In fact when looking through documentation only the server seems to have that option.  Via reading online it seems to me that their server is just not responding correctly or at all:
Passive FTP

In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.

In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1023) and sends the PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data.

From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

    * FTP server's port 21 from anywhere (Client initiates connection)
    * FTP server's port 21 to ports > 1023 (Server responds to client's control port)
    * FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
    * FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)
Thanks again for all of your help!
yes, i saw that too.  i looked through my filezilla installation and i don't see where that's specified.  seems the ftp server is "listening" on ephemeral ports 60000-60100 and the filezilla client knows that passive ftp could use port 1024 through 65535.  if you don't tell your ftp server to listen to that port range, then you have to tell your ftp client to use that port range.

it shouldn't be this difficult...all fingers are pointing at them?  even if you opened up NAT for the 1024 - 65535 port range, if their server isn't expecting that port range, then the connection will fail.  i think that's why were not seeing packets from their server being dropped.
My thoughts as well.
perhaps you can change the ephemeral port range on the client side.

Microsoft Windows

As of Windows Vista and Windows Server 2008, Windows now uses a large range (49152-65535) by default, according to Microsoft Knowledgebase Article 929851. That same article also shows how you can change the range if desired, but the default range is now sufficient for most servers.

For older Windows operating systems (Windows XP and older), Windows uses the traditional BSD range of 1024 through 4999 for its ephemeral port range.  Unfortunately it appears that you can only set the upper bound of the ephemeral port range.  Here is information excerpted from Microsoft Knowledgebase Article 196271:

    * Start Registry Editor (Regedt32.exe).
    * Locate the following key in the registry:
    * On the Edit menu, click Add Value, and then add the following registry value:

      Value Name: MaxUserPort Data Type: REG_DWORD Value: 65534 <for example>

      Valid Range: 5000-65534 (decimal) Default: 0x1388 (5000 decimal)

      Description: This parameter controls the maximum port number used when an application requests any available user port from the system. Normally, ephemeral (that is, short-lived) ports are allocated between the values of 1024 and 5000 inclusive.
    * Quit Registry Editor.

Note: There is another relevant KB article (812873) which claims to allow you to set an exclusion range, which could mean that you could exclude ports 1024-9999 (for example) to have the ephemeral port range be 10000-65534. However, we have not been able to get this to work (as of October 2004).

I'm going to shy away from registry edits for an issue that is most likely on their end. I'm trying to get in touch with their IT group to fix this issue.
i agree.