active FTP doesn't work with NAT

[bqbauer]

This is with a 64-bit OpenSolaris host (2009.06). It happens with all tested guests (XP, Ubuntu, OpenSolaris, Solaris 10), both with NAT and bridged networking. The problem did not exist prior to 3.0.0, and has been confirmed both with pre-existing guests and newly created guests.

When you open an FTP session from the guest to the OpenSolaris host, the host returns an error like this one from a NAT guest:

Jun 21 19:50:21 fnog ftpd[1902]: [ID 227848 daemon.warning] refused PORT 10.0.2.15,60783 from fnog [192.168.99.22]

192.168.99.22 is the host IP.

If you do the same with VB 2.2.4 on the same host, ftpd logs no errors and successfully connects the guest. This has been tested on two different hosts. Both tested installations of the host OS use an unmodified default ftp configuration.

With FTP servers on the Internet, VB guests connect, but are unable to list files or directories on the FTP server using either the 'ls' or 'dir' commands. The same FTP servers interact normally with computers that are not VB guests. One tested example would be ftp.sunfreeware.com.

Shared folders and SSH/SCP/SFTP exhibit no observed problems from guest to host, but are slower for large transfers and for network testing.

I will be attaching a log file soon.

[Frank Mehnert]

Actually this sounds like a duplicate of #4343.

[bqbauer]

Not fixed in 3.0.2, and I don't know if that means it's a different problem or not. I never attached the file because of the above comment, so is that needed since 4343 is reopened, do we wait and see?

[vasily Levchenko]

Doest it change anything if you switch ftp client to passive mode?

[vasily Levchenko]

Have send test build for verification.

[bqbauer]

Passive does not work with 3.0.2, and XP clients do not have a passive option at the command line. Regarding bridged networking, it appears I was in error with the initial report, or that 3.0.2 fixed this problem for bridged network interfaces.

Passive mode works with 3.0.3 on a UNIX client to the host. HOWEVER, NAT networking beyond the host is virtually useless as described in bug #4343. This includes XP and OpenSolaris guests.

To reiterate, none of this was a problem with 2.2.4, and passive mode was never required prior to 3.0, and not all clients can enter passive mode.

[vasily Levchenko]

Replying to bqbauer:

Passive does not work with 3.0.2, and XP clients do not have a passive option at the command line. Regarding bridged networking, it appears I was in error with the initial report, or that 3.0.2 fixed this problem for bridged network interfaces.

Windows clients are switched with passive command

Passive mode works with 3.0.3 on a UNIX client to the host. HOWEVER, NAT networking beyond the host is virtually useless as described in bug #4343. This includes XP and OpenSolaris guests.

To reiterate, none of this was a problem with 2.2.4, and passive mode was never required prior to 3.0, and not all clients can enter passive mode.

The real NAT and firewalls require access via passive. Old ability to access via active connection was able because emulation of FW punching.

[vasily Levchenko]

I'd recommend you to open new bug about active ftp connection with closing this bug.

[bqbauer]

Clarification: XP does not support passive from its command line.

What do you mean "Windows clients are switched with passive command"? I don't understand.

This bug is about the FTP problem, so why open a new bug about the same problem?

[vasily Levchenko]

Replying to bqbauer:

Clarification: XP does not support passive from its command line.

What do you mean "Windows clients are switched with passive command"? I don't understand.

Some years ago for Windows ftp.exe clients used following formula

# ftp ftp.netbsd.org
> user anonymous
> password: [email protected]
> quote pasv

but it seems doesn't work for modern ftp.exe. workaround could be ncftp

This bug is about the FTP problem, so why open a new bug about the same problem?

It isn't the same problem the problem was for accessing host in passive mode (which is recommended on forums). and this problem is fixed. active accessing is different. your guest open listening socket and server connects to it.

[nixtrian]

this is vsftpd log, when succesfully connected from vbox 2.2.4

Wed Jul 15 00:33:14 2009 [pid 2808] [ftp] FTP response: Client "192.168.1.3", "230 Login successful."
Wed Jul 15 00:33:14 2009 [pid 2808] [ftp] FTP command: Client "192.168.1.3", "SYST"
Wed Jul 15 00:33:14 2009 [pid 2808] [ftp] FTP response: Client "192.168.1.3", "215 UNIX Type: L8"
Wed Jul 15 00:33:20 2009 [pid 2808] [ftp] FTP command: Client "192.168.1.3", "PORT 192,168,1,3,159,233"
Wed Jul 15 00:33:20 2009 [pid 2808] [ftp] FTP response: Client "192.168.1.3", "200 PORT command successful. Consider using PASV."

this is vsftpd log when PORT command fails:

Tue Jul 14 22:04:09 2009 [pid 7747] FTP command: Client "192.168.1.3", "USER anonymous"
Tue Jul 14 22:04:09 2009 [pid 7746] [ftp] OK LOGIN: Client "192.168.1.3", anon password "<no_password>"
Tue Jul 14 22:04:09 2009 [pid 7752] [ftp] FTP response: Client "192.168.1.3", "230 Login successful."
Tue Jul 14 22:04:14 2009 [pid 7752] [ftp] FTP command: Client "192.168.1.3", "PORT 10,0,2,15,19,137"
Tue Jul 14 22:04:14 2009 [pid 7752] [ftp] FTP response: Client "192.168.1.3", "500 Illegal PORT command."

clearly, the extarnal vbox-NAT IP is wrong

[nixtrian]

this is not only on solaris host. my host type is archlinux

[vasily Levchenko]

Replying to nixtrian:

this is not only on solaris host. my host type is archlinux

The passive ftp fixed will be available in 3.0.4

[vasily Levchenko]

Replying to nixtrian:

this is vsftpd log, when succesfully connected from vbox 2.2.4

Wed Jul 15 00:33:14 2009 [pid 2808] [ftp] FTP response: Client "192.168.1.3", "230 Login successful."
Wed Jul 15 00:33:14 2009 [pid 2808] [ftp] FTP command: Client "192.168.1.3", "SYST"
Wed Jul 15 00:33:14 2009 [pid 2808] [ftp] FTP response: Client "192.168.1.3", "215 UNIX Type: L8"
Wed Jul 15 00:33:20 2009 [pid 2808] [ftp] FTP command: Client "192.168.1.3", "PORT 192,168,1,3,159,233"
Wed Jul 15 00:33:20 2009 [pid 2808] [ftp] FTP response: Client "192.168.1.3", "200 PORT command successful. Consider using PASV."

this is vsftpd log when PORT command fails:

Tue Jul 14 22:04:09 2009 [pid 7747] FTP command: Client "192.168.1.3", "USER anonymous"
Tue Jul 14 22:04:09 2009 [pid 7746] [ftp] OK LOGIN: Client "192.168.1.3", anon password "<no_password>"
Tue Jul 14 22:04:09 2009 [pid 7752] [ftp] FTP response: Client "192.168.1.3", "230 Login successful."
Tue Jul 14 22:04:14 2009 [pid 7752] [ftp] FTP command: Client "192.168.1.3", "PORT 10,0,2,15,19,137"
Tue Jul 14 22:04:14 2009 [pid 7752] [ftp] FTP response: Client "192.168.1.3", "500 Illegal PORT command."

clearly, the extarnal vbox-NAT IP is wrong

PORT is active ftp (not supposed to work over NAT) mode and I'm currently working on it.

[jrmayfield]

I see the same problem running VirtualBox 3.0.10_54097_fedora 11. My wireshark logs are very similar to the vsftpd logs that nixtrian posted on 2009-07-16.

[Henri Daumas]

I see the exact same problem:

Test:

Run netshark on the host machine to capture the 10.x incoming-outgoing packets seen on the host side Connect from an ftp client within the client o/s (WinXP) to ANY external ftp server in active mode.

Result:

Outgoing connection works fine (N > 1023, client port N -> connects to ftp server port 21) Client sends to ftp server the reverse data connection port as N+1 Server attempts to connect back to client port N+1, which fails, causing a 'hang' in the client

One can analyze the netshark packets and see the attempt from the FTP server connect back to port N+1 on the client

Version: VirtualBox-3.1-3.1.2_56127_openSUSE111-1.x86_64 Host: openSUSE 11.2 Client: Windows XP SP3

(note: I ported this VM over to VMware Server 2.0.2 and found VMware's active FTP capability to work just fine there.)

The VB NAT implementation should detect and allow the reverse active FTP data connection. This doesn't appear to be implemented.

[mcandre]

Getting similar behavior with the default OS/2 Warp FTP client. When I try to download WarpIN, hosted via FTP, then the get command complains:

500 Illegal PORT command.

I get the same behavior with the client specifying passive mode enabled, which is said to not actually be implemented in the native OS/2 Warp FTP client unfortunately.

​https://comp.os.os2.apps.narkive.com/De2Q1OOA/ftp-passive-mode-in-os-2

I have not tried bridged mode as a workaround, though fortunately WebExplorer is able to successfully complete FTP file transfers with vbox NAT. While WebExplorer would not make for a great CLI automation candidate, I am currently invoking WebExplorer via Packer scripted boot_command / scancodes, so at least the GUI operation is effectively automated for the WarpIN download specifically.