IIS FTP 8.5 DataChannel timeout with a linux client

Question

I've got a strange situation. Hope someone can help. I've got two independent IIS FTP servers.

1. a) IIS 7.5 runs as standalone VM
2. b) IIS 8.5 runs on Azure VM (windows server 2012 R2)

When I connect to these ftp servers using FileZilla, both work as expected, really well. Passive mode, no problem.

When one of my customer's linux client is connecting, it works great on the IIS 7.5, but it does not work on the IIS 8.5

It stops after the PASV command with a timeout. The linux client is running some app on fedora which has FTP incorporated in it.

For authentication i'm using IIS Manager Users.

Does anyone have an idea of what this could be? Or how to troubleshoot this?? I can test, and see everything working, except when the clients processes are entering the scene!

After hours of trying stuff ... i turned off the windows firewall entirely on the IIS 8.5, and added some allow 'all ports' to the Azure firewall ... but no help. To me it seems like something in Azure or in the new version of IIS FTP 8.5...could that be?

After installing Wireshark on the IIS 8.5 srvr, i got this:

230 User logged in.
USER someuser
PASS somepassword
TYPE A
200 Type set to A.
PASV
227 Entering Passive Mode (xxx,166,145,222,20,18).
ABOR
226 ABOR command successful.

Packets:

297 15.067087   ###.41.121.116  10.0.0.4    FTP 72  Request: PASV
298 15.067223   10.0.0.4    ###.41.121.116  FTP 117 Response: 227 Entering Passive Mode (XXX,166,145,222,20,18).
300 15.083895   ###.41.121.116  10.0.0.4    TCP 66  39240 → 21 [ACK] Seq=46 Ack=143 Win=5888 Len=0 TSval=1985344095 TSecr=659594
370 19.338991   10.0.0.4    ###.41.121.116  TCP 86  [TCP Retransmission] 21 → 58522 [PSH, ACK] Seq=72 Ack=40 Win=131072 Len=20 TSval=660021 TSecr=1985339032
431 23.746259   ###.41.121.116  10.0.0.4    FTP 72  Request: ABOR
432 23.746366   10.0.0.4    ###.41.121.116  FTP 96  Response: 226 ABOR command successful.
433 23.762471   ###.41.121.116  10.0.0.4    TCP 66  45877 → 21 [ACK] Seq=7 Ack=31 Win=46 Len=0 TSval=1985352774 TSecr=660462

packages 299, 301-369, 371-430 belong to other processes (RDP mostly)

Answer 1

I see a TCP retransmission before the abortion. Could please confirm if the packet 370 is a retransmission of packet 298? If yes, it means the server doesn't get any response from client when it sends out the packet 298 (Entering Passive Mode). The most common cause of this issue is that the Azure block the connection from client to the server's data channel.

We are able to limit the port used as data channel in IIS. Then we can add these ports into the Azure firewall to make sure that the client can initiate the data transmission to the server.

Here is a good guide about it.

========================================

Update

If you are using Azure in Resource Manager mode (ARM), you will need to open the ports in the Network Security Group. Here is a good article about the difference between ARM and ASM in network.

If you did open the port in Azure correctly and it still doesn't work, then please try to perform the network capture on both of server and client side at same time to find out the dropped packets.

If the client doesn't receive the "Entering Passive Mode" packet from server, then please check the outbound firewall on server side and the inbound firewall on client side.

If the client receives the packets from server but doesn't respond to it. Then it should be a client side issue.

If the client sends out the response to server but the server doesn't receive it, then you should re-check if the ACLs in the network security group are correct. If you are sure about it, then you may need to open a ticket with Azure support to perform the network capture on the azure host to find what drops the packets.