Not able to upload file from different LAN in Centos
 

We have centos i our server..

Well a client wants to host their website with us...We can upload it form the LAN but it is not possible form different LAN.. What could be the reason?

The iptables -L shows:

if ftp port 20 is closed how are we able to upload it from the LAN then

upload how?? there are a dozen ways to move a file between two systems.

upload using ftp client..

The customer who wants to upload his website is in different country...When we tested by uploading a file from our LAN it worked..

so FTP is obviously a nasty protocol to get through a firewall, in what way does it not work? does it never log in, or do files specifically not transfer? have they tried using active and passive mode? could they use sftp instead for a much simpler experience?

your rulebase in "iptables -vnL" format might be more useful.

how do we do that?

do what?

ya they can login but they arent able to upload their site..

u told abt passive and active mode and also abt ssftp so was asking abt dat...

abt? really?

if this server has a single interface then it looks like the issue for ftp-data connections failing is likely to be down to something else between them and you that you don't have locally, your public firewall, or theirs etc. you can check lsmod to see that the ftp conntrack module is loaded, but if it's working for you it sounds like it already is.

Again, your full rule base would possibly help here.

Well ya we can upload it using their username and password from our LAN but they are not able to upload it from there..We don't have any firewalls out here though but i guess ftp port 20 has been blocked somewhere in the acl of router for outsiders..

And by 'full rule base' do you mean the iptables rules?

FTP port 20 is not a destination port in FTP. In active mode that is the *SOURCE* port of the connection created by the *SERVER* to the client. In passive mode, it's not used, unless the ftp server is explicitly tethered to use that as the data port. So it's not likely to be that it's blocked, but that a device is not inspecting the ftp control traffic to track the data connections validity, so being rejected implicitly.

http://www.linuxhowtos.org/Misc/ftpmodes.htm

That means when we login in directly we are using active ftp right? And for that in our iptables rule we should give it as sport instead of dport right?

Well can you please have a look at my iptables rule above and comment on it because it's given as sport so..

no, the login / control data flow is identical, it's how the additional ftp data connection is established, which you don't do yourself, is the difference. With sftp etc, these things do not exist, so if sftp is available, they would do better to use that instead.

yet again you've not provided the rulebase as requested, but in reality it can't really matter. if it works for you, the server rulebase is not the issue.

well de output of ipables -vnL is:

Is it in our configuration part to login either via active or passive?

And it also means ftp port 20 is dport only right?

you can see that the counters there say just about nothing has hit port 20. that line is not relevant to the ftp environment. files already sent over ftp will be being covered by the "RELATED" entry.

yet again though, the problem is likely to be elsewhere. You're using this box fine from where you are, and the rulebase makes no distinction between you or anyone else.

oh k k... Thanks..

Well my iptables rules contain:

So is the rules ok or should i make it to sport for ftp port 20?

And i have read it somewhere that we should add the pasv_max_port and pasv_min_port mentioned in the vsftpd.conf file along with the tcp port 20 and 21 in iptables...how far is that true?

well yes you can force the max and min ports to match up with static rules on the OTHER DEVICE that is not inspecting the traffic, but you need to find that device first.

Oh please don't say that...

It's just that i'm not understanding properly that's y..