Dynamic Port Assignment with an NSA2650
Corey716 Newbie ✭
I'm having problems with the Dynamic Port Assignment of the Sonicwall NSA2650 when it comes to ftp. When I enter “Passive FTP” which is a passive port range of 50100-50149 we established, passive ftp sessions work and active sessions don’t. When I enter “FTP (ALL) which is ports 20 and 21, active ftp sessions work and passive sessions do not. When I try and combine both groups of ports, I have all sorts of problems. Has anybody else experienced this problem or have a solution to my dilemma?
Category: Mid Range Firewalls
Hey! You will be signed out in 60 seconds due to inactivity. Click here to continue using the site.
What do you mean you "enter passive ftp"? Are you hosting the FTP service behind the firewall or just trying to access one? You haven't given much info.
Have you read any KB articles?
We are hosting an ftp server in a DMZ zone behind the firewall. And yes I read both articles. Thanks.
Apparently, we are the only ones having this problem. Technical support has been useless. It is a big problem when it comes to active ftp connections. Once a customer issues a PORT command followed by a LIST, they receive a 425 Cannot open data connection error. This indicates to me that the firewall is not allowing the data port to connect correctly which is what the Dynamic Port Assignment is supposed to handle. Very frustrating.
Run a packet capture on the sonicwall watching the exact traffic. If there is a drop after the LIST command is executed than investigate the cause of the drop...
When I try and combine both groups of ports, I have all sorts of problems. Has anybody else experienced this problem
You need to give more detail, we can't help you with what you've given so far. The packet capture TKWITS suggested should reveal what ports really are in use, and therefore, what ports you need to allow for this to work.
The whole thing is bizarre. Everything was working and then last August we started having problems with active ftp sessions both inbound to the DMZ and outbound to the Internet from the LAN. Absolutely no firewall or networking changes were made. So, I upgraded to the latest firmware on the firewall but that did not resolve the problem.
A couple of days ago I worked with SonicWall support to at least have the correct response from the DMZ ftp server when I ask for a directory listing from my PC that is in the private network (LAN). Before the change I could not get a directory in an active ftp session.
We added an Access Rule from DMZ to LAN, Source Port: Any, FTP high end ports (50,000-65,535), Source: DMZ_ftp_service, Destination: Any.
Once added, I can now receive directory information from the ftp server on the DMZ to PC's on our internal network (LAN). Apparently, the firewall was not letting the ftp server to respond with directory and file information on the data channel.
Now, I need the same response available to clients on the Internet (WAN) when accessing our DMZ ftp server. Again, this is only a problem with active ftp, not passive ftp. Also, no TLS security is involved. This is strictly a plain ftp session.
So, I set up another Access Rule from DMZ to WAN, Source Port: Any, FTP high end ports (50,000-65,535), Source: DMZ_ftp_service, Destination: Any. But still no luck. I'm assuming that I need a NAT policy for this as well.
As for packet captures, I have run them until I'm blue in the face. They don't seem to tell me much. (Now, I'm not that proficient with reading packet captures.) I do know that is definitely a firewall issue not allowing responses through the data channel when it comes to active ftp sessions.
In a packet capture, you are looking for what is being dropped by the firewall. Look at source/dest ip/port combination, amend firewall rules to match. Dropped packets are highlighted in red.
I need the same response available to clients on the Internet (WAN) when accessing our DMZ ftp server
So, I set up another Access Rule from DMZ to WAN, Source Port: Any, FTP high end ports (50,000-65,535), Source: DMZ_ftp_service, Destination: Any.
Sounds to me like you have this backwards. You need a WAN to DMZ rule, not DMZ to WAN.
And yes, you do need to consider NAT policies for inbound connections.....but with this object-based firewall policy stuff, generally speaking, I use the same service objects in the access rule and the NAT policy. When I discover I need to add these ports to some port forward I did 6 months ago, all I am doing is adding more services to the service group that is in use on the access rule and the NAT policy, so only one change to make.
Everything works now to the best of my knowledge. I just recreated new NAT policies shown here:
Both active and passive ftp connections worked in my testing. I'm still confused why this whole thing started being a issue. I do know that I have had problems before when I create a rule from some completely different service that seems to change priorities of NAT policies. The SonicWall is very testy when it comes to that. Thanks for your help!
IIRC Filezilla changed the way they handle Passive FTP a few years ago and mucked up a bunch of stuff. Maybe your server application did a similar thing.
BTW the first KB article I posted answered your question.
This problem had absolutely nothing to do with passive ftp. So, the article you sent was no help. Nor was this a FileZilla issue. Passive ftp worked throughout the entire time. It was active ftp clients from the WAN that were not receiving a valid reply from the data channel due to the firewall blocking outbound replies. My guess is the reflexive NAT policy was needed in order for this to all work correctly.
Im not here to argue, but the subject of the post is 'Dynamic Port Assignment ...' which implies Passive FTP. You mention "Passive FTP" multiple times in your original post.
Pardon my believing this was about passive ftp...
Nor I'm I. I truly appreciate your input and being a Newbie I may have mislabeled my problem. I wasn't sure where the problem was which had been going on for months. I contacted support so many times that I was getting very frustrated. Anyway, it works now and that's all that matters. Thank you!