Results 1 to 2 of 2
I have proFTPd setup on an Ubuntu server with 12 network interfaces, each one connected to a separate DSL line. The server binds to the 12 interfaces fine but has ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 06-21-2007 #1
- Join Date
- May 2007
Routing issue with FTP transfers in BINARY mode
- Each DSL line has a dynamic IP and is mapped to a DynDNS name.
- Each interface is behind a NAT in the DSL router. (An incoming connection is able to get to the server so the incoming NAT is working fine)
- All relevant ports are opened for FTP on each router and forwarded to the appropriate internal IP
- Each interface in proFTPd is setup to use a DNS service to lookup the interface IP for PASV transfers. Each interface has a different DNS name
- All interfaces are visible and enabled in the interface list
- Each of the interfaces has an internal IP of 192.168.n.11 and the router has an IP of 192.168.n.1.
- The server is running Ubuntu Server 6.10 with no firewall software
With these routes I was able to ftp to each interface independently and get directory listings. I am also able to upload data from the client to each of the 12 interfaces.
ip route add 192.168.2.0/24 dev eth2 src 192.168.2.11 table r2
ip route add 192.168.3.0/24 dev eth3 src 192.168.3.11 table r3
ip route add 192.168.12.0/24 dev eth12 src 192.168.12.11 table r12
ip rule add from 192.168.2.11 table r2
ip rule add from 192.168.3.11 table r3
ip rule add from 192.168.12.11 table r12
ip route add default via 192.168.2.1 table r2
ip route add default via 192.168.3.1 table r3
ip route add default via 192.168.12.1 table r12
As you can see, each interface has its own default route and then there is one global default route for eth0/first interface.
On this first interface all traffic is fine and I am able to ftp in and out in all modes correcty. Only the interfaces that are higher than this one have a problem.
I also tried loading ip_conntrack and ip_conntrack_ftp but that did not work. I also added the following iptable entries but they didn't help either.
iptables -A INPUT -i eth2 -p tcp --sport 1024: --dport 1024: -d 192.168.2.11 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth2 -p tcp --sport 1024: --dport 1024: -s 192.168.2.11 -m state --state ESTABLISHED -j ACCEPT
I have also tried several ftp clients.
I have run Wireshark to trace the packets during the ftp sessions and there does not seem to be any significant differnce between the way the ftp daemon is handling ASCII vs BINARY transfers. They both seem to follow an almost identical pattern.
So now I am able to do the following using PASSIVE mode
- Upload from Client -> Server in ASCII and BINARY mode
- Download from Server -> Client in ASCII mode only.
Does anyone have an idea as to what routing setting could be blocking Binary transfers but not the control channel and not ascii?
- 06-21-2007 #2
1. I hope ip_forwarding is enabled. Can you recheck?
2. Is the FORWARD chain of iptables is ACCEPT?
3. Can you run tcpdump on the interface where you suspect the problem is, in order to know whr the packet is getting dropped?
4. Hope you r allowing TCP port 20 and 21
5. If possible, can you post the outputs of
iptables -L -v
iptables -L -t nat -v---------------------------------
Registered Linux User #440311
HI2ARUN _AT_ GMAIL _DOT_ COM