Visit Open-E website
Results 1 to 2 of 2

Thread: sFTP through firewall (WAN)

  1. #1
    Join Date
    Oct 2006
    Location
    France
    Posts
    25

    Default sFTP through firewall (WAN)

    Hello,

    I've make some tests in NAS-R3 Ent. in demonstration mode with the sFTP functionnality.

    sFTP access from LAN :
    Operates successfully with FileZilla using FTP over TLS (Using explicit encryption)
    sFTP access from WAN :
    Connect successfully but unable to retrieve directory listing

    This problem is the same i have with "NAS XSR Entreprise" edition, it seems to be a feature now, not a bug !?!

    The problem was analysed by myself and reported to the support team (3, November 2006) as :

    The network configuration is this one :

    Client(192.168.2.126) --- |firewallA|------Internet-------|firewallB|------NAS server(192.168.1.10)

    Where firewall B has NAT activated, and the TCP ports 20 and 21 are forwarded to the NAS server.

    Case 1 : Client is in passive mode
    The client connect and then, receive the following message :

    [17:03:30] Command: PASV
    [17:03:30] Response: 227 Entering Passive Mode (192,168,1,10,136,254).
    [17:03:30] Command: LIST
    [17:03:51] Error: Transfer channel can't be opened.

    We can see here that the NAS server sends its internal IP address and some random TCP port for the client to connect to, but the IP is an internal IP and the TCP port are so random that i can't open them on the firewall.
    I guess it would work if i could modify the following "proftp" server variables :

    MasqueradeAddress ftp.mydomain.com
    PassivePorts 65530 65535

    Then i could open the 65530-65535 TCP ports onto my firewall, to allow passive communication with the client.

    Case 2 : Client is in active mode
    The client connect and then, receive the following message :

    [17:04:23] Status: Connected
    [17:04:23] Status: Retrieving directory listing...
    [17:04:23] Command: PWD
    [17:04:23] Response: 257 "/" is current directory.
    [17:04:23] Command: TYPE A
    [17:04:23] Response: 200 Type set to A
    [17:04:23] Command: PORT 192,168,2,126,16,46
    [17:04:23] Response: 500 Illegal PORT command
    [17:04:23] Error: Could not retrieve directory listing

    Here, the message "Illegal PORT command" tells the client to activate "passive mode", and i'm back in case 1.

    Documentations used :
    * http://slacksite.com/other/ftp.html
    * http://www.castaglia.org/proftpd/doc...HOWTO-NAT.html
    * http://www.castaglia.org/proftpd/doc...HOWTO-TLS.html
    * http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
    * http://support.ipswitch.com/kb/WS-19980722-BK01.htm
    * http://support.ipswitch.com/kb/WS-20001228-DM04.htm

    I'm not an FTP expert, so, please, correct me if i am wrong:
    In conclusion, my feeling is if you allow users to modify the configuration variables "MasqueradeAddress" and "PassivePorts", it would be possible for the server to tell the FTP client where to connect using passive mode.
    If not, the Open-e FTP server setup is simply unusable when both client and server are protected by a firewall, and it is the case everywhere in the enterprise world.
    Also, it would not be the case if we were using FTP instead of SFTP cause our firewall would have read FTP packets and would be able to see the request for a passive transfert but it is another problem, and i'm glad you choose SFTP instead of FTP.

    Thanks for your help.

    Regards,
    ---
    Mathieu

  2. #2

    Default

    Once again your research is well documented!! I just tested a pre-release of NAS-R3 Enterprise ver. 4.12 build 2659 (on our FTP site for those who wish to test) and this worked over a WAN > NAT on my test server but without selecting the Encryption settings SSL/TLS. I tested with the SSL/TLS settings with Port 22 selection on server and left the Firewall open for all ports just to test and still was not able to get a directory listing (similar to your scenario). So they must be working on this with the new release of 4.12. I have asked engineers to see about the Renew issue as well, so now let's wait and see from version 4.12 from the release notes and if they will have the renew feature as well.

    Thanks again Mathieu for your hard work!!
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •