Jonathan, On Thursday 07 February 2002 08:20, you said something about: > How do you know that their ftp program switches to the LAN ip address? > > I think that it's a firewall issue. FTP, by default, opens up a > connection BACK TO the clients to transmit data (including directory > listings). Your firewall is most likely blocking those connections. Have > your clients use "passive mode" and see if they connect (passive mode > causes the data transfers to occur on the original connection, rather than > starting one that goes back to the client.
Actually, to clarify (just picking nits really, but I think it's important to be accurate), in "standard" FTP, the client would initiate the control connection and the server would initiate the data connection back to it. This was a problem for firewalls because the server would normally choose a port that was blocked by the average firewall. Using PASV (passive) mode, the client intiates both the control _and_ the data ports and the server responds appropriately. > > RH 6.2, ProFtpd server, behind a firewall. I'm having problems with some > > clients who are trying to ftp into the machine. They can access the > > server with the www IP address, but immediately after authentication > > their ftp program switches to the LAN ip address, 198... and they are not > > able to upload files. My guess is that the local ftp client is reading > > the LAN ipaddress from "hostname -i" and switching to it. > > > > 1) How do I change the ipaddress the server sends back to ftp programs, > > etc., so it reads the necessary IP address; 216.254... but doesn't knock > > me off the LAN. > > > > 2) Is there a way to configure these Windows ftp clients so they don't do > > a hostname -i lookup, or so that ProFTPd sends back the correct IP > > address? You may want to try the above, but I won't say if it will work or not. My suggestion... Are you using a "VirtualHost" directive? If not, you probably should be. That way you control how the server is reporting what it should be called. Else you are likely having the connection initialized at the first address, being given the internal hostname (not the virtual one you first tried to connect on) and then having that address in turn resolved differently. -- Brian Ashe CTO Dee-Web Software Services, LLC. [EMAIL PROTECTED] _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
