HAproxy in PROXY mode and data connection fails

[michaelrommel]

Hi,

I seem to be unable to configure both pieces of the puzzle correctly:

haproxy.cfg, the proxy has the IP 172.16.29.101:

frontend ftp_control
    bind *:21
    bind *:20
    bind *:30000-49999
    mode tcp

    default_backend             ftp_server_control

backend ftp_server_control
    mode tcp
    balance     leastconn
    stick-table type ip size 100k expire 1h
    stick on src

    server-template aeroftp- 20 0.0.0.0 check port 21 disabled send-proxy

The backend IP address is later updated via the haproxy stats socket.

libunftp code: the server has the IP 172.16.31.93

    let passive_host = env::var("HAPROXY_IP").unwrap();
    let server6 = libunftp::ServerBuilder::new(Box::new(move || backend.clone()))
        .authenticator(Arc::new(authenticator))
        .shutdown_indicator(async move {
            shutdown.recv().await.ok();
            println!("Shutting down FTP server");
            libunftp::options::Shutdown::new().grace_period(Duration::from_secs(11))
        })
        .idle_session_timeout(600)
        .proxy_protocol_mode(21)
        // .passive_host(libunftp::options::PassiveHost::FromConnection)
        .passive_host(&*passive_host)
        .passive_ports(30000..=49999)
        .metrics()
        .build()
        .map_err(|e| format!("Could not build server: {}", e))?;

The client has the IP 172.16.2.137. The connection goes through to the libunftp server, but the data connection fails. The client sees correctly the IP of the HAproxy in the PASV reply:

227 Entering Passive Mode (172,16,29,101,135,143)

but then no connection can be established.

The logfile tells me something weird: it says it tries to bind on the IP address of the HAproxy and not its own:

March 5, 2026, 17:09 | INFO libunftp::server::controlchan::control_loop > Control connection was closed., username: test, source: 172.16.2.137:58474, trace-id: 0xee9c3a033c2a1d7a
March 5, 2026, 17:09 | INFO libunftp::server::ftpserver::listen_prebound > Unregistering active data channel port because the control channel is closing SwitchboardKey { source: 172.16.2.137, port: 34703 }
March 5, 2026, 17:08 | INFO libunftp::server::ftpserver::listen_prebound > Received internal message to allocate data port
March 5, 2026, 17:08 | INFO libunftp::server::controlchan::commands::pasv > Listening on passive port 172.16.29.101:34703
March 5, 2026, 17:07 | INFO libunftp::server::controlchan::commands::pass > PASS: User DefaultUser logged in, source: 172.16.2.137:58474, trace-id: 0xee9c3a033c2a1d7a
March 5, 2026, 17:07 | INFO libunftp::server::ftpserver::mode::proxy > Incoming proxy connection from Ok([::ffff:172.16.29.101]:59798)
March 5, 2026, 17:07 | INFO libunftp::server::ftpserver::mode::proxy > Incoming control connection: SocketAddrPair { source: 172.16.2.137:58474, destination: 172.16.29.101:21 } (Ok([::ffff:172.16.29.101]:59798))(control port: Some(21))
March 5, 2026, 17:07 | INFO libunftp::server::controlchan::control_loop > Starting control loop, source: 172.16.2.137:58474, trace-id: 0xee9c3a033c2a1d7a

Why is the libunftp daemon then trying to listen on the haproxy IP?

What am I doing wrong here?

Michael.

[michaelrommel]

I think the message was misleading. It just tells, that this connection info was sent out to the client. There are actual data packets flowing through to libunftp, but only 3 packets or so. Then everything stops. I have no idea, what's going on. I had that working without proxy mode without problems.

[robklg]

yeah good point about the misleading message. I’ll see if I have some time to reproduce this in the weekend.

[michaelrommel]

I got it working now on port 2121. I think it is a haproxy config error on my side. Let me dig deeper into it, before you spend time on it. It is the first time I am working with haproxy, so that is most likely my own fault.

[michaelrommel]

The issue was solely on my side. Here is what happened:

I prepared the haproxy to distribute the load across many backend containers, so I went with a haproxy config with server-templates. In those templates, the documentation states:

"port" is an optional port specification. If set, all connections will
be sent to this port. If unset, the same port the client
connected to will be used. The port may also be prefixed by a "+"
or a "-". In this case, the server's port will be determined by
adding this value to the client's port.

So I left it unset which worked for the normal non-PROXY-protocol mode, as the high-port data connections are left untouched and routed through to the backend. I configure the backends using the stats socket of haproxy, issuing a set server backend/instance addr 1.2.3.4 command. Now after switching to PROXY mode this command MUST be amended with a port 21 statement! That I was missing.

[robklg]

Ah nice to hear! And do you then do some source ip based hashing for the routing rules?

[michaelrommel]

The stick-table of HAproxy should take care of that:

    stick-table type ip size 100k expire 1h
    stick on src

But it seems I hit another dead end, as the HAproxy does not support Active FTP. I may have to redesign everything to run on EC2 instances and do the loadbalancing in the Linux Kernel using ip_vs_ftp and ipvsadm with netfilter... Topic for the coming week... Have a nice weekend...