Opened 12 years ago
Closed 8 years ago
#7859 closed Bug report (rejected)
Outgoing connection always bypass routing table and bind on the same IP as control connection in site-to-site transfer — at Version 1
| Reported by: | cheng zhi | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | FileZilla Server |
| Keywords: | Cc: | ||
| Component version: | Operating system type: | Windows | |
| Operating system version: | 2003 |
Description (last modified by )
Server A has two NIC which runs FileZilla Server, client connect to server A through NIC1, and issue a PORT command to server B, but server B is only reachable through NIC2.
After dig in source, I find CreateTransferSocket always bind PORT socket on the same IP as the control socket to avoid Windows Firewall problem, but in my scenario, this cause server A alway try to connect server B through NIC1 which is unreachable, although routing table is properly configured.
Change History (1)
comment:1 by , 8 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → rejected |
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
This is necessary to ensure interoperability with clients expecting a matching data connection IP in order to mitigate FTP data connection stealing attacks.
Especially if using IPv6 with enabled privacy extensions, failure to bind the data connection IP has adverse effects.
Generally you should avoid server-to-server transfers, they aren't secure.