0

I know there are a ton of similar questions already, but I've read through just about everything I could find and am still having trouble resolving my specific issue.

Problem: I am having difficulty transferring data to an external FTP server, but only from an FTP client running on a server located inside my DMZ. Transferring from an FTP client works fine from any machine inside my LAN.

A brief overview of my environment:

I have a Sonicwall SOHO router/firewall with the following interfaces configured/connected:

  • X0: LAN
  • X1: WAN (single, static IP from ISP)
  • X2: DMZ (a single server that functions as a web server and FTP server is connected to this interface)

I am confident in my NAT policies - People can connect to MY FTP server just fine, and I can connect to other FTP servers from inside my DMZ - there's only one specific server where this is a problem. The connection used to work fine before I upgraded my firewall from a Cisco SA520 to the Dell Sonicwall SOHO. I will also note that while I can connect to other FTP servers, those servers connect in passive mode, so it could be an issue with active mode connections. Currently, the problem server only accepts active mode from my IP.

My current thinking is that it's a firewall issue on my end, but I can't understand why. My Firewall rules are pretty simple:

LAN > WAN Allow all
DMZ > WAN Allow all
WAN > LAN Deny all
WAN > DMZ Allow Server Services (HTTP, HTTPS, FTP (All) (TCP 20, 21, 49152 - 65535))
WAN > DMZ Deny all

I also have the following rule set in my advanced firewall settings:

Enable FTP Transformations for TCP port(s) in Service Object: FTP (All) 

("FTP (All)" service object uses the same ports listed above - TCP 20, 21, 49152 - 65535).

I am not very confident in what this rule is doing, but I think this is what allows passive connections to my server from external sources. However, I don't know if it is causing problems when I am trying to connect to external sources.

--

Using the Sonicwall's packet monitor, I am able to login to the server and issue a PORT command which returns a 200 PORT successful response. However, after the LIST command is issued, my server never ACKs the SYN message (frame #57/58) sent by the FTP server. The FTP Server then retransmits the SYNs (frame 64/65 and 72/73). When it doesn't receive an ACK in the timeout window, it times out. Here is some output from the Sonicwall's packet monitor during an attempted connection:

No. Time        Source      Destination Protocol    Length  Info
53  3.750000    My DMZ IP   FTP Server  FTP         60      Request: LIST
54  3.750000    My WAN IP   FTP Server  FTP         60      Request: LIST
55  3.783334    FTP Server  My WAN IP   FTP         108     Response: 150 Opening BINARY mode data connection for /bin/ls.
56  3.783334    FTP Server  My DMZ IP   FTP         108     Response: 150 Opening BINARY mode data connection for /bin/ls.
57  3.783334    FTP Server  My WAN IP   TCP         62      20 → 61011 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
58  3.783334    FTP Server  My DMZ IP   TCP         62      20 → 61011 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
59  4.000000    My DMZ IP   FTP Server  TCP         60      61010 → 21 [ACK] Seq=88 Ack=289 Win=65280 Len=0
60  4.000000    My WAN IP   FTP Server  TCP         54      26752 → 21 [ACK] Seq=91 Ack=289 Win=65280 Len=0
64  6.683334    FTP Server  My WAN IP   TCP         62      [TCP Retransmission] 20 → 61011 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
65  6.683334    FTP Server  My DMZ IP   TCP         62      [TCP Retransmission] 20 → 61011 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
72  12.633334   FTP Server  My WAN IP   TCP         62      [TCP Retransmission] 20 → 61011 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
73  12.633334   FTP Server  My DMZ IP   TCP         62      [TCP Retransmission] 20 → 61011 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

(Note that any missing frames in the sequence above are due to other traffic I filtered out from this view).

From my LAN machine, the ACK is sent back after the LIST command and data transfers work just fine.

--

So while I have diagnosed it to this point, I don't know what to do next. The router doesn't say it's dropping any packets or blocking anything due to a firewall rule. Any ideas as to why my LAN machine sends the ACK but the DMZ machine doesn't?

  • In the PORT (or EPRT) command that your FTP client is sending to the problem server, is the LAN IP address used, or the IP address of your router/gateway? Also, does the port indicated in that PORT/EPRT command fall within the 49152 - 65535 range? – Castaglia May 3 '16 at 19:23
  • The PORT command is issued with my WAN IP (after being translated by the router) and the 200 response comes back to my WAN IP (which is then translated back by the router). The port in that command is always within the 49152 - 65535 range. In this case, the command was specifically: PORT <IP>,233,83 which calculates to port 61011 (the port where the TCP transmission was attempted and failed). – Gage Trader May 3 '16 at 19:31
  • PORT <IP>,233,83 calculates to port 59731: (233 * 256) + 83 = 59731. But I suspect that's not the real issue -- unless something is rewriting port numbers along the way. If possible, you might try FTPS, which (at the very least) would prevent any network middleboxes from spying/manipulating the control connection messages. – Castaglia May 3 '16 at 19:36
  • Sorry, I mis-typed the value - it was 238,83. The server I'm connecting to doesn't support FTPS for whatever reason. I always configure my connection to use TLS, if possible, but their server responds with "500 'AUTH SSL': command not understood" – Gage Trader May 3 '16 at 19:57
  • OK. What do your DMZ > LAN rules look like (that's the one entry not mentioned in your firewall rules list)? – Castaglia May 3 '16 at 20:01
1

I had a similar problem with a device form Pitney Bowes in the LAN zone. I resolved it by updating the Sonicwall to firmware 6.2.7.1-23n.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.