FTPS / FTP TLS WAN access broken again?

[jappish84]

Just noticed yesterday that my brother couldn't reach my FTP share over TLS, this has been working great for a long time. I found this old thread where DATA ports weren't dynamically opened, and I'm having the exact same symptoms as described in the old thread. @RMerlin refers to a fix in the post, but it seems the issue has been reintroduced in some version, not sure when. I was on 384.13 yesterday, and tried again on 384.13_2 today, but the issue persists. I'm running the server on RT-AC3200, if that makes any difference.

Is it safe to use the workaround mentioned by @AirMaxVI, originally provided by @octopus until this hopefully gets fixed?

 

[ColinTaylor]

I've just compared the old "fixed" source code with the current code and they appear to be identical. Check the contents of your /etc/vsftpd.conf file. It should include these 3 lines:

pasv_enable=YES
pasv_min_port=57530
pasv_max_port=57560

 

[jappish84]

I just checked, and the three lines are identical to yours. This must mean that something else has changed?

Like I wrote before, the symptoms are identical to the old post, meaning I get the same error message as described, I can connect when on LAN, and I can connect if I disable TLS

 

[ColinTaylor]

Can you just double check that the iptables rule is also present:

iptables-save | grep 57530

EDIT: If you have a VPN client enabled I suggest you try disabling that and testing again.

 

[octopus]

Just noticed yesterday that my brother couldn't reach my FTP share over TLS, this has been working great for a long time. I found this old thread where DATA ports weren't dynamically opened, and I'm having the exact same symptoms as described in the old thread. @RMerlin refers to a fix in the post, but it seems the issue has been reintroduced in some version, not sure when. I was on 384.13 yesterday, and tried again on 384.13_2 today, but the issue persists. I'm running the server on RT-AC3200, if that makes any difference.

Is it safe to use the workaround mentioned by @AirMaxVI, originally provided by @octopus until this hopefully gets fixed?

Working fine here with 384.14, using tls.

 

[jappish84]

Can you just double check that the iptables rule is also present:

iptables-save | grep 57530

This is the output:

-A INPUT -p tcp -m tcp --dport 57530:57560 -j ACCEPT

EDIT: If you have a VPN client enabled I suggest you try disabling that and testing again.

I had two VPN clients running, and a VPN server, tried disabling all three but unfortunately it made no difference.

Working fine here with 384.14, using tls.

unfortunately 384.14 isn't available for the RT-AC3200.


Odd, I know it has been running fine earlier, even with both a VPN server and a client running.

 

[ColinTaylor]

Maybe your external IP address has changed. Have you verified what you see in the router's GUI matches that returned by canyouseeme.org

 

[Grisu]

At least you could update to Asuswrt-Merlin 384.13_2 (RT-AC87U and RT-AC3200).

 

[jappish84]

Maybe your external IP address has changed. Have you verified what you see in the router's GUI matches that returned by canyouseeme.org

I've made sure, and I can see in the Filezilla logs that the initial connection is successful, and I get greeted by the server, but in the next step, TLS auth fails. As mentioned earlier, I have no issues connecting after TLS is disabled.

Here's the Filezilla output:

Status:          Resolving address of domain.asuscomm.com
Status:          Connecting to xx.xxx.xxx.xx:21...
Status:          Connection established, waiting for welcome message...
Response:     220 Welcome to ASUS RT-AC3200 FTP service.
Command:    AUTH TLS
Response:     502 Command not implemented.
Command:    AUTH SSL
Error:            Could not read from socket: ECONNRESET - Connection reset by peer
Error:            Could not connect to server
Status:          Waiting to retry...

@Grisu

As mention in first post, the issue is present under both 384.13 and 384.13_2

 

[ColinTaylor]

Here's the Filezilla output:

Can you increase the debug level to see if it gives any more information.

 

[octopus]

Make sure username and password match, they needed first login before ssl/tls handshake.

 

[jappish84]

Can you increase the debug level to see if it gives any more information.

Here's the output with debug on lvl 4:

10:44:37 Status:          Resolving address of domain.asuscomm.com
10:44:38 Status:          Connecting to xx.xxx.xxx.xx:21...
10:44:38 Status:          Connection established, waiting for welcome message...
10:44:38 Trace:           CFtpControlSocket::OnReceive()
10:44:38 Response:     220 Welcome to ASUS RT-AC3200 FTP service.
10:44:38 Trace:           CFtpLogonOpData::ParseResponse() in state 1
10:44:38 Trace:           CControlSocket::SendNextCommand()
10:44:38 Trace:           CFtpLogonOpData::Send() in state 2
10:44:38 Command:    AUTH TLS
10:44:38 Trace:           CFtpControlSocket::OnReceive()
10:44:38 Response:     502 Command not implemented.
10:44:38 Trace:           CFtpLogonOpData::ParseResponse() in state 2
10:44:38 Trace:           CControlSocket::SendNextCommand()
10:44:38 Trace:           CFtpLogonOpData::Send() in state 3
10:44:38 Command:    AUTH SSL
10:44:38 Trace:           CFtpControlSocket::OnReceive()
10:44:38 Error:            Could not read from socket: ECONNRESET - Connection reset by peer
10:44:38 Trace:           CRealControlSocket::DoClose(66)
10:44:38 Trace:           CControlSocket::DoClose(66)
10:44:38 Trace:           CFtpControlSocket::ResetOperation(66)
10:44:38 Trace:           CControlSocket::ResetOperation(66)
10:44:38 Trace:           CFtpLogonOpData::Reset(66) in state 3
10:44:38 Error:            Could not connect to server
10:44:38 Trace:           CFileZillaEnginePrivate::ResetOperation(66)
10:44:38 Status:          Waiting to retry...

@octopus

I've made sure, and I can connect from WAN when TLS is disabled, and I can connect from LAN even with TLS enabled, so username and passwd are fine

 

[octopus]

Try with other program than Filezilla. If I remember right that have som trouble to connect to FTP.

 

[jappish84]

Try with other program than Filezilla. If I remember right that have som trouble to connect to FTP.

My experience is the opposite, Filezilla never failed. I have also tried kodi's ftp client, same issue


Anyone on 384.13 or 384.13_2 that can test it out on their router, just to see if it's my system or something else

 

[jappish84]

Since I seem to be the only one experiencing these issues, and nobody seems able to confirm them, then I'll try resetting to defaults and try with a clean config and see if the issue persists. I'll report back when done, probably some time during the holidays

 

[jappish84]

Ok, so I just reset the router to factory defaults., cleared nvram and went through reconfiguring my Wifi, USB share, DDNS, let's encrypt and DHCP address list, nothing else, meaning I left VPN clients and servers for later and I still have the same issue as described above.

I'm sure I've configured it correctly since it has been working great before, just not sure when it stopped working. The share is still accessible through LAN, and accessible from WAN when TLS is disabled. If there's anything else I can try, I'd be glad to.

Otherwise, I really hope this is something you could find some time to take a look at for the coming releases @RMerlin

Thanks

 

[octopus]

Ok, so I just reset the router to factory defaults., cleared nvram and went through reconfiguring my Wifi, USB share, DDNS, let's encrypt and DHCP address list, nothing else, meaning I left VPN clients and servers for later and I still have the same issue as described above.

I'm sure I've configured it correctly since it has been working great before, just not sure when it stopped working. The share is still accessible through LAN, and accessible from WAN when TLS is disabled. If there's anything else I can try, I'd be glad to.

Otherwise, I really hope this is something you could find some time to take a look at for the coming releases @RMerlin

Thanks

Working fine here with 384.15_Alpha1, using tls. Just tested from wan-side.

 

[jappish84]

Thanks for testing. Unfortunately, 384.13_2 is the latest release available for the RT-AC3200. Maybe the issue is model specific?

 

[octopus]

Thanks for testing. Unfortunately, 384.13_2 is the latest release available for the RT-AC3200. Maybe the issue is model specific?

Do you use:
FTPS (Explicit) FTP over TLS/SSL

And what hostname do you use?
Do it work inside your lan?

 

[jappish84]

Do you use:
FTPS (Explicit) FTP over TLS/SSL

And what hostname do you use?
Do it work inside your lan?

Yes, the config requires FTPES when connecting when TLS is enabled (I don't think you can change this in the webui?)

It's working fine over LAN, using the public domain name, username and password.

I also discovered that it's working when connected to the routers guest network where intranet access is disabled.

Connecting through a mobile Hotspot, using the same client and settings spits put the error described earlier.

Disabling TLS and connecting using the same client and settings on mobile Hotspot, connects fine. I've described this earlier, and thus I'm sure the client/connection info is not the problem