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 - server flooding control connection

Hi all,

I'm sure ftp downloads used to work a while ago.
Now, when i try to access an ftp server it fails.
The ftp proxy live log shows: 
2008:11:15-12:22:16 (none) frox[6988]: Connect from 172.22.0.122
2008:11:15-12:22:16 (none) frox[6988]: ... to 143.166.11.10()
2008:11:15-12:23:16 (none) frox[6988]: Server flooding the control connection
2008:11:15-12:23:16 (none) frox[6988]: Closing session 

I could not find any info on this on the web, exepct the literal text in the frox sources.

Any help?

(My astaro connects directly to the internet using a adsl modem in bridge. the external address is fixed. I tried enabling/disabling all network security settings like tcp flood protection and the like. I have a masquerading rule set up, and 2 packet rules: allow any source address ftp protocol to the iternal network, and allow any protocol to any address from internal network. Firmware version: 7.305  Pattern version: 8699)


This thread was automatically locked due to age.
Parents
  • Seems to happen after sending QUIT, but shouldn't matter. I can login to that server with user anonymous and download files without any problems.
  • Seems to happen after sending QUIT, but shouldn't matter. I can login to that server with user anonymous and download files without any problems.


    I have this problem with all server I wiant to connect to, not only this one.
    Given the fact that I do not see much about this problem on the forum, I expect I have incorrectly configured the firewall.
    But I do not understand where I am wrong.

    Regards, Robin.
  • Regardless of this messages, does ftp work? Can you post the log of commands from your ftp-client?
  • I discovered that FTP starts to work fine when I disable a NAT rule.

    On the Internet side, I have a public stack of 5 ip-addresses.
    I have a dnat rule that applies to one this addresses;
    route external port 21 on the the last address of my stack to an inside servers rdp port.

    Disabling this rule, fixed the FTP problem.

    At the moment I'm converting to another broadband connection with only one ip address, because for a private person the 5-ip stack becomes too expensive.
    So I have to find another way to route traffic to rdp anyway, but a discussion on that off-topic here.

    However, I think the above problem should not happen: the dnat rule applies only to one external address. (say the fifth address of the stack)
    My masquerading rule is set to the first address of my ip-stack.
    So in my opinion a client gets masqueraded to the first address of my stack, and should receive ftp connections back becuase they also will be send to the first address of the stack, and therefore the dnat rule does not apply.
Reply
  • I discovered that FTP starts to work fine when I disable a NAT rule.

    On the Internet side, I have a public stack of 5 ip-addresses.
    I have a dnat rule that applies to one this addresses;
    route external port 21 on the the last address of my stack to an inside servers rdp port.

    Disabling this rule, fixed the FTP problem.

    At the moment I'm converting to another broadband connection with only one ip address, because for a private person the 5-ip stack becomes too expensive.
    So I have to find another way to route traffic to rdp anyway, but a discussion on that off-topic here.

    However, I think the above problem should not happen: the dnat rule applies only to one external address. (say the fifth address of the stack)
    My masquerading rule is set to the first address of my ip-stack.
    So in my opinion a client gets masqueraded to the first address of my stack, and should receive ftp connections back becuase they also will be send to the first address of the stack, and therefore the dnat rule does not apply.
Children
  • Try turning off the 'Autommatic packet filter rule' on the DNAT and see if that also solves the problem (of course, you'll need to write the explicit PF rule).  If it does, then I think you can report a bug!

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA