Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 1767 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FTP again

mrseq
I'm trying to teach my astaro to enable pasv ftp access to my ftp-server for the outside world.

My Astaro is connected to the Internet via PPPoE (DSL). It has a static DNS Name (eg ftp.somewhere.org) with dynamic IP (aka Dyndns). My FTP Server is located right behind the firewall, has a private IP (192.168.0.100) and is running glftpd.

On my Firewall, I defined the following things:

-----------------------------

NETWORKS
FTP_SERVER 192.168.0.100 255.255.255.255 

SERVICES
FTP_PASV tcp 10000:10050 10000:10050 

SERVICE GROUPS
ftp FTP
    FTP_PASV 
   
NAT-RULES
Name Match parameters    SRC translation    DST translation   
dsl-masq Internal_Network__ -> All / All MASQ__External None
ftp-nat All -> External_Interface__ / FTP None    FTP_SERVER 
ftp-pasv-nat All -> External_Interface__ / FTP_PASV None    FTP_SERVER

PACKET FILTER RULES
From (Client)  Service  To (Server) Action 
Any { ftp }  FTP_SERVER  Allow
FTP_SERVER { ftp }  Any  Allow

-----------------------------
Now for the ftp-server part...

glftpd docs say:
pasv_addr  [1]
Determines what IP/Host is used for passive mode.

If you want glftpd to bind to this interface (for example, if you use
more than one NIC in the same box and you want passive connections to
not use the default one), just do "pasv_addr x.x.x.x".  If you want
glftpd to only report this IP to the client but to bind to the default
interface (as in when your box only has an internal IP and you're using
NAT), do "pasv_addr x.x.x.x 1".

so my glFTPd is configured as follows:

-----------------------------

allow_fxp       yes     yes     yes     *
pasv_addr       ftp.somewhere.org 1
pasv_ports      10000-10050

-----------------------------

When clients connect to my server the PORT-way it works like a charm.
But the passive way it still does not work... they see my current public IP (since I added the pasv_addr to my config) and get a port in the correct range (in this example 39*256+61=10045).

227 Entering Passive Mode (my,current,public,ip,39,61) 

But then they get a "Data Socket Error: Connection refused" error...  I don't get whats wrong with my setup...

First, I thought of an error in my Packet Filter rules:

PACKET FILTER RULES
From (Client)  Service  To (Server) Action 
Any { ftp }  FTP_SERVER  Allow

I think incoming packets would never go to FTP_SERVER but to the EXTERNAL_INTERFACE__, right?
But since I put an ANY ANY ANY ALLOW rule on top of my ruleset with no success this can't be the real 'error'...

Any Ideas (besides "forget the PASV Mode" [:)] )?
     


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to JimmyM
    Strange.. after a reboot this config seems to work well. Now people can connect to my server via PASV and PORT.
    However my error didn't disappear but is now limited to fxp-connections.

    I asked a friend to fxp a test-file to my server. Here's his client output:

    200 PORT command successful.
    STOR test
    425 Can't build data connection: Connection refused.
    Transfer Failed!
    TYPE A
    200 Type set to A.

    Then I checked the kernel-log and found the following:

    2003-Oct 11 11:38:44 (none) kernel: ip_conntrack: max number of expected connections 1 of ftp reached for ip.of.my.friend-?.227.226.79, reusing

    What does that mean? I've read that I should try modprobe ip_nat_ftp. But that module is already loaded:

    $ lsmod | grep ip_nat_ftp
    ip_nat_ftp              3072   0  (unused)
    iptable_nat            15284   8  [ipt_REDIRECT ipt_MASQUERADE ip_nat_h323 ip_nat_snmp_basic ip_nat_proto_gre ip_nat_irc ip_nat_pptp ip_nat_ftp]
    ip_conntrack           17620   7  [ipt_REDIRECT ipt_MASQUERADE ip_conntrack_h323 ip_nat_h323 ip_conntrack_irc ip_nat_irc ip_conntrack_pptp ip_nat_pptp ip_conntrack_proto_gre ipt_state ip_nat_ftp iptable_nat ip_conntrack_ftp

    When I asked him to retry, he had the same error. But this time I had no(!) addition to my kernel log... In fact I can't find his IP in any of the other logs, although the connection is obviously still refused by me.. 

    Btw.: I changed the FTP_PASV definition to what Jim M. suggested. Thanks Jim.