remote ftp ssl access failed
-
pfSense has no FTP access. It has no FTP server, so you can't use a FTP client to access it.
FTP is a protocol that should be avoided at any cost, as it is very insecure.
Any decent FTP client has also a SFTP client build in these days. -
sftp is not the same as ftp over tls.. (ftps) which uses port 990 if in implicit mode..
Problem when you encrypt the data channel and want to use active mode.. Pfsense can not see what port to open inbound..
But that would not be the error your seeing..
I just tested this - and works just fine here.. Not sure what ports you have open, the default lan is any rule.. Not sure what your attempting to do with
"I opened all ports from 1024 to 65535"
That doesn't include port 21 ;) which is what ftps in explicit mode would use
If you use implicit mode it would be port 990, still outside that 1024-65k range. Also works here.
What are the rules you have on your interface in pfsense where you test client is that your using test connection with? Mine is on lan with default any any rule..
if you have your outbound rules locked down - you would have to allow for the control channel port your wanting to use 21, or 990, and then for the data connection port using passive which really could be anything. Your 1024-65k rule should be fine for that.. But such a rule does not allow the control channel port.
Just to be complete in this write up - I set mode to active.. And while I have my client set to send the correct public IP.. It won't work because the ftp active helper can not open the port on pfsense for the connection from the server to client in active mode. And I don't have the active ports forwarded by hand.. But as you can see that is not related to the control channel connection
in the port command you see 23,116 which is the port in this session of 6004 (23x256+116)
And you can see it blocked on pfsense.
As mentioned by @Gertjan I would move away from ftp be it using ftps or ftpes or not..
-
@johnpoz I confirm that in the modality:
require implicit FTP over TLS
I don't have problems.My problem is only when I use the mode:
require explicit FTP over TLSif I understand what you are saying, my problem is in the configuration of the LAN Rules, I am attaching an image.
Do I need to change this rules?
Thanks.
-
@sasa1 your lan rules are not the problem.. Those are the default any any rule - all traffic would be allowed. If you can not connect to the server for some reason a block upstream?
Here I set to what you stated..
This would use port 21 for the control channel
Status: Resolving address of test.rebex.net Status: Connecting to 195.144.107.198:21... Status: Connection established, waiting for welcome message... Response: 220 Microsoft FTP Service Command: AUTH TLS Response: 234 AUTH command ok. Expecting TLS Negotiation. Status: Initializing TLS... Status: Verifying certificate... Status: TLS connection established. Command: USER demo Response: 331 Password required for demo. Command: PASS ******** Response: 230 User logged in. Command: SYST Response: 215 Windows_NT Command: FEAT Response: 211-Extended features supported: Response: LANG EN* Response: UTF8 Response: AUTH TLS;TLS-C;SSL;TLS-P; Response: PBSZ Response: PROT C;P; Response: CCC Response: HOST Response: SIZE Response: MDTM Response: REST STREAM Response: 211 END Command: OPTS UTF8 ON Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON. Command: PBSZ 0 Response: 200 PBSZ command successful. Command: PROT P Response: 200 PROT command successful. Status: Logged in Status: Retrieving directory listing... Command: PWD Response: 257 "/" is current directory. Command: TYPE I Response: 200 Type set to I. Command: PASV Response: 227 Entering Passive Mode (195,144,107,198,4,7). Command: LIST Response: 150 Opening BINARY mode data connection. Response: 226 Transfer complete. Command: PASV Response: 227 Entering Passive Mode (195,144,107,198,4,9). Command: LIST -a Response: 150 Opening BINARY mode data connection. Response: 226 Transfer complete. Status: Calculating timezone offset of server... Command: MDTM readme.txt Response: 213 20140408140939 Status: Timezone offset of server is 7200 seconds. Status: Directory listing of "/" successful Status: Retrieving directory listing of "/aspnet_client"... Command: CWD /aspnet_client Response: 250 CWD command successful. Command: PWD Response: 257 "/aspnet_client" is current directory. Command: PASV Response: 227 Entering Passive Mode (195,144,107,198,4,11). Command: LIST -a Response: 150 Opening BINARY mode data connection. Response: 226 Transfer complete. Status: Directory listing of "/aspnet_client" successful
Works just fine.. Using passive for the data channel.. You can see above in the PASV command and then the server sends me the IP and port to connect too. Which via your outbound rules would be allowed without any problem.. With ftp there is a control channel connection and a data channel connection. if you can not connect control, then you never can get a data channel. If you connect with control, then be it using active or passive will determine who starts the conversation for the data connection..
What is the specific error your seeing in filezilla when you test.. Turn on detailed log view if you want to get a bit more info.. Your first posted error has to do with trying to use the sftp port while trying to do ftps..
ftps be it explicit would use port 21 for control channel.. Implicit uses port 990.
-
@johnpoz the error messagges are:
Stato: In attesa di un nuovo tentativo...
Stato: Risoluzione dell'indirizzo IP test.rebex.net in corso
Stato: Connessione a 195.144.107.198:21...
Stato: Connessione stabilita, in attesa del messaggio di benvenuto...
Risposta: 220 Microsoft FTP Service
Comando: AUTH TLS
Risposta: 234 AUTH command ok. Expecting TLS Negotiation.
Stato: Inizializzazione TLS...
Errore: Errore GnuTLS -110: The TLS connection was non-properly terminated.
Stato: Il server non ha correttamente chiuso la connessione TLS
Stato: Tentativo di connessione con "ECONNABORTED - Connessione interrotta" non riuscito.
Errore: Impossibile collegarsi al serverthanks.
-
@sasa1 said in remote ftp ssl access failed:
Errore: Errore GnuTLS -110: The TLS connection was non-properly terminated.
What version of filezilla are you using? I am on 3.55.0 which is current.
-
@johnpoz the filezilla version is:
3.54.1I have updated to version 3.55 but the result does not change
thanks.
-
@sasa1 I would update, and then turn on detailed logging..
Right click in the log window area
You might want to turn on debug as well
Then your log will look like this
Status: Resolving address of test.rebex.net Status: Connecting to 195.144.107.198:21... Status: Connection established, waiting for welcome message... Trace: CFtpControlSocket::OnReceive() Response: 220 Microsoft FTP Service Trace: CFtpLogonOpData::ParseResponse() in state 1 Trace: CControlSocket::SendNextCommand() Trace: CFtpLogonOpData::Send() in state 2 Command: AUTH TLS Trace: CFtpControlSocket::OnReceive() Response: 234 AUTH command ok. Expecting TLS Negotiation. Trace: CFtpLogonOpData::ParseResponse() in state 2 Status: Initializing TLS... Trace: tls_layer_impl::client_handshake() Trace: tls_layer_impl::continue_handshake() Trace: TLS handshake: About to send CLIENT HELLO Trace: TLS handshake: Sent CLIENT HELLO Trace: tls_layer_impl::on_send() Trace: tls_layer_impl::continue_handshake() Trace: tls_layer_impl::on_read() Trace: tls_layer_impl::continue_handshake() Trace: tls_layer_impl::on_read() Trace: tls_layer_impl::continue_handshake() Trace: tls_layer_impl::on_read() Trace: tls_layer_impl::continue_handshake() Trace: tls_layer_impl::on_read() Trace: tls_layer_impl::continue_handshake() Trace: TLS handshake: Received SERVER HELLO Trace: TLS handshake: Processed SERVER HELLO Trace: TLS handshake: Received CERTIFICATE Trace: TLS handshake: Processed CERTIFICATE Trace: TLS handshake: Received CERTIFICATE STATUS Trace: TLS handshake: Processed CERTIFICATE STATUS Trace: TLS handshake: Received SERVER KEY EXCHANGE Trace: TLS handshake: Processed SERVER KEY EXCHANGE Trace: TLS handshake: Received SERVER HELLO DONE Trace: TLS handshake: Processed SERVER HELLO DONE Trace: TLS handshake: About to send CLIENT KEY EXCHANGE Trace: TLS handshake: Sent CLIENT KEY EXCHANGE Trace: TLS handshake: About to send FINISHED Trace: TLS handshake: Sent FINISHED Trace: tls_layer_impl::on_read() Trace: tls_layer_impl::continue_handshake() Trace: TLS handshake: Received FINISHED Trace: TLS handshake: Processed FINISHED Trace: TLS Handshake successful Trace: Protocol: TLS1.2, Key exchange: ECDHE-SECP521R1-RSA-SHA1, Cipher: AES-256-CBC, MAC: SHA1 Trace: tls_layer_impl::verify_certificate() Status: Verifying certificate... Trace: CFtpControlSocket::SetAsyncRequestReply Status: TLS connection established. Trace: CControlSocket::SendNextCommand() Trace: CFtpLogonOpData::Send() in state 6 Command: USER demo Trace: CFtpControlSocket::OnReceive() Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 331 Password required for demo. Trace: CFtpLogonOpData::ParseResponse() in state 6 Trace: CControlSocket::SendNextCommand() Trace: CFtpLogonOpData::Send() in state 6 Command: PASS ******** Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 230 User logged in. Trace: CFtpLogonOpData::ParseResponse() in state 6 Trace: CControlSocket::SendNextCommand() Trace: CFtpLogonOpData::Send() in state 10 Command: OPTS UTF8 ON Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON. Trace: CFtpLogonOpData::ParseResponse() in state 10 Trace: CControlSocket::SendNextCommand() Trace: CFtpLogonOpData::Send() in state 11 Command: PBSZ 0 Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 200 PBSZ command successful. Trace: CFtpLogonOpData::ParseResponse() in state 11 Trace: CControlSocket::SendNextCommand() Trace: CFtpLogonOpData::Send() in state 12 Command: PROT P Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 200 PROT command successful. Trace: CFtpLogonOpData::ParseResponse() in state 12 Status: Logged in Trace: Measured latency of 128 ms Trace: CFtpControlSocket::ResetOperation(0) Trace: CControlSocket::ResetOperation(0) Trace: CFtpLogonOpData::Reset(0) in state 15 Trace: CFileZillaEnginePrivate::ResetOperation(0) Trace: CControlSocket::SendNextCommand() Trace: CFtpListOpData::Send() in state 0 Status: Retrieving directory listing... Trace: CFtpChangeDirOpData::Send() in state 0 Trace: CFtpChangeDirOpData::Send() in state 1 Command: PWD Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 257 "/" is current directory. Trace: CFtpChangeDirOpData::ParseResponse() in state 1 Trace: CFtpControlSocket::ResetOperation(0) Trace: CControlSocket::ResetOperation(0) Trace: CFtpChangeDirOpData::Reset(0) in state 1 Trace: CFtpListOpData::SubcommandResult(0) in state 1 Trace: CControlSocket::SendNextCommand() Trace: CFtpListOpData::Send() in state 2 Trace: CFtpRawTransferOpData::Send() in state 0 Trace: CFtpRawTransferOpData::Send() in state 1 Command: TYPE I Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 200 Type set to I. Trace: CFtpRawTransferOpData::ParseResponse() in state 1 Trace: CControlSocket::SendNextCommand() Trace: CFtpRawTransferOpData::Send() in state 2 Command: PASV Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 227 Entering Passive Mode (195,144,107,198,4,9). Trace: CFtpRawTransferOpData::ParseResponse() in state 2 Trace: CControlSocket::SendNextCommand() Trace: CFtpRawTransferOpData::Send() in state 4 Trace: Binding data connection source IP to control connection source IP 192.168.9.100 Trace: tls_layer_impl::client_handshake() Trace: Trying to resume existing TLS session. Command: LIST -a Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 150 Opening BINARY mode data connection. Trace: CFtpRawTransferOpData::ParseResponse() in state 4 Trace: CControlSocket::SendNextCommand() Trace: CFtpRawTransferOpData::Send() in state 5 Trace: tls_layer_impl::on_send() Trace: tls_layer_impl::continue_handshake() Trace: TLS handshake: About to send CLIENT HELLO Trace: TLS handshake: Sent CLIENT HELLO Trace: tls_layer_impl::on_read() Trace: tls_layer_impl::continue_handshake() Trace: TLS handshake: Received SERVER HELLO Trace: TLS handshake: Processed SERVER HELLO Trace: TLS handshake: Received FINISHED Trace: TLS handshake: Processed FINISHED Trace: TLS handshake: About to send FINISHED Trace: TLS handshake: Sent FINISHED Trace: TLS Handshake successful Trace: TLS Session resumed Trace: Protocol: TLS1.2, Key exchange: ECDHE-SECP521R1, Cipher: AES-256-CBC, MAC: SHA1 Trace: tls_layer_impl::verify_certificate() Trace: CTransferSocket::OnConnect Trace: CTransferSocket::OnReceive(), m_transferMode=0 Trace: tls_layer_impl::on_read() Trace: CTransferSocket::OnReceive(), m_transferMode=0 Trace: CTransferSocket::TransferEnd(1) Trace: tls_layer_impl::shutdown() Trace: tls_layer_impl::continue_shutdown() Trace: CFtpControlSocket::TransferEnd() Trace: tls_layer_impl::on_read() Trace: CFtpControlSocket::OnReceive() Response: 226 Transfer complete. Trace: CFtpRawTransferOpData::ParseResponse() in state 7 Trace: CFtpControlSocket::ResetOperation(0) Trace: CControlSocket::ResetOperation(0) Trace: CFtpRawTransferOpData::Reset(0) in state 7 Trace: CFtpListOpData::SubcommandResult(0) in state 3 Trace: CFtpControlSocket::ResetOperation(0) Trace: CControlSocket::ResetOperation(0) Trace: CFtpListOpData::Reset(0) in state 3 Status: Directory listing of "/" successful Trace: CFileZillaEnginePrivate::ResetOperation(0)
Which will show us more info about the TLS exchange..
You could also try clearing your cached certs? If your on windows that would be here "%APPDATA%\FileZilla"
There is a trustedcerts.xml file.
Once you have cleared the certs - you should see popup like I showed in my connections with details of the cert they are presenting you.
-
@johnpoz I deleted the trustedcerts.xml file, enabled verbose logging and debugging.
I attach files with the errors received.
Thanks.
debug 4.txt -
Looks like you never got the hello back..
Traccia: tls_layer_impl::client_handshake() Traccia: tls_layer_impl::continue_handshake() Traccia: TLS handshake: About to send CLIENT HELLO Traccia: TLS handshake: Sent CLIENT HELLO Traccia: tls_layer_impl::on_send() Traccia: tls_layer_impl::continue_handshake() Traccia: tls_layer_impl::on_read() Traccia: tls_layer_impl::continue_handshake() Traccia: tls_layer_impl::on_read() Traccia: tls_layer_impl::continue_handshake() Traccia: tls_layer_impl::failure(-110)
Maybe you could update your timeout? I believe it defaults to 60 seconds.. Maybe yours is lower, or you could say up it to 120 seconds? The way I read that is you never got the answer back from the client hello - server hello..
For sanity shake you could sniff on pfsense wan when you try it.. You should be able to see what is sent and gotten back.. But yeah never going to get far if you never get the server hello back to work out the handshake..
Are you doing any sort of vpn on pfsense, do you have multiple wan connections? Anything like that?
-
@johnpoz I took the timed-out to 120 seconds but to no avail.
yes there is an active vpn with openswan.I disabled the vpn but unfortunately the result does not change
Thanks.
-
Could you route your connection to this ftps server around that vpn..
If you capture your traffic and disable the ftp decode wireshark will do on it - you can then view the tls info.. So example here sniff via a connection... You can see my client hello and then the server hello..
-
@johnpoz I disabled the vpn connection and removed the rules related to the vpn but unfortunately the problem remains the same.
Thanks. -
Well if they don't send you a server hello - then no you would not be able to connect.
A sniff will show you what pfsense sees on its wan in return.. There would be no reason pfsense would not send this traffic to your client if it actually got it..
-
@johnpoz do i have to use wireshark or can i use logs generated by pfsense?
thanks. -
No you sniff with pfsense (diagnostic packet capture) - its just the log they show in that output even with full info set is going to be hard to read.. Just do the sniff and then download it and open it with wireshark.. Makes it much easier to view/read/understand, etc.
You can set it to only capture the IP of the ftps server.. 195.144.107.198 so its not all that big.. And has only the data your interested in vs all the other traffic that flowing.
You will have to tell wireshark not to decode it as ftp - which is what it will most likely auto do.. Then it would look like this..
What your interested in is the tls stuff - so telling wireshark not to decode as ftp will make it easier to see the tls stuff..
The view the package capture ok depending on what specific your looking for - but for something like this download the capture and use your fav network analyzer.. Unless you think you could make heads or talls of this ;)
-
This post is deleted! -
-
That is not the wan.. Do the packet capture on pfsense.. Just download it to view in wireshark..
And I showed you exactly how to disable the ftp decode wireshark is doing..
But even that can see 195.x sending you a FIN... Closing the session..
-
@johnpoz I have installed wireshark on the server where I use Filezilla, from this server can I connect wireshark to control the pfsense WAN traffic or do I have to install wireshark on pfsense?
Thanks.