FTP Server in passive mode with HAProxy Frontend and Backend nodes
Dear all, I have to put to work an FTP server (Filezilla) in my backend network, as this: Internet -- Firewall -- HAProxy Frontend -- HAProxy Backend -- FTP server (passive mode) This is my configuration in my HAProxy FE: frontend Frontend_FTP bind *:21 bind *:2-20010 mode tcp option tcplog timeout client 1h default_backend HAProxy_BE backend HAProxy_BE mode tcp server HAProxy-Node-2 172.17.17.1:21 check port 21 This is my configuration in my HAProxy BE: frontend Backend_FTP bind *:21 bind *:2-20010 mode tcp option tcplog timeout client 1h default_backend FTP_Server backend FTP_Server mode tcp server HOST-FTP 10.12.1.4:21 check port 21 The FTP control session works OK, but the data session fails. Is there any error in the HAProxy configuration files from Frontend and Backend? Special thanks, regards!!!
Re: HTTP/3 -- POST requests not working
On 4/14/22 03:27, Amaury Denoyelle wrote:
So to summary, this option should be activated if you only have browsers
as client and the traffic is big enough to saturate haproxy queues.
I hope this will clarify your thoughts,
Thanks for that detail. For these setups, I really doubt that there
will ever be that many requests. Unless I get hit by a DDOS attack. :)
I am having further problems with http/3. Randomly in the webmail it
will get a 403 error when accessing a URL for the site. Checking the
log history, looks like it's on POST requests, which were already
problematic. I guess removing abortonclose doesn't completely fix POST
requests.
Apr 14 07:11:15 - haproxy[2357875] 199.192.164.74:54388
[14/Apr/2022:07:11:15.227] web~ be-apache-81/bilbo 2/0/76/-1/85 403 1371
- - LHVN 1/1/0/0/0 0/0 {webmail.elyograg.org} "POST
/mail/?_task=mail&_action=refresh HTTP/3.0"
And something that has occasionally happened with anything I've enabled
http/3 on ... firefox will get into a mode where accessing an http/3
enabled site will completely hang, and the only way to get that website
working again is to close the browser, reopen it, and try again. I've
also seen this in Chrome, so it doesn't seem to be browser-specific. I
do most of my testing in Firefox, because on the work machine Chrome has
a proxy, which won't do http/3.
So for now I've only enabled http3 on a select subset of websites.
These problems make the webmail not work right. I hope any information
I gather will speed up development on QUIC so it can move out of
experimental status.
Ah, git pull has revealed a lot of changes, some of which are on quic
code. I will get that built and installed.
Thanks,
Shawn
Re: HTTP/3 -- POST requests not working
On Wed, Apr 13, 2022 at 08:16:06AM -0600, Shawn Heisey wrote:
> On 4/13/22 02:42, Amaury Denoyelle wrote:
> > Ok this seems related to 'option abortonclose'. Without this, I do not
> > have a 400 error. Can you confirm me this behavior on your side please ?
>
> If I remove that, it works. I can have my webmail served via http/3 and
> login still works, which it didn't before because all POST requests were
> getting a 400.
> What am I losing or gaining by removing abortonclose? I read the docs on
> it, and wasn't able to work out whether I want it or not. Will this failure
> when configuring abortonclose be considered a bug?
Currently, this option is buggy when used with a QUIC listener. This is
indeed a bug and will be fixed in a future patch.
> The reasons for that option being in the config are lost to the antiquities
> of time. Most of my config is stolen from a setup I once built at an old
> ${DAYJOB} that was actually doing load balancing. For my personal setups, I
> mainly use haproxy for SSL offloading and making multiple private-side web
> servers available through a single public IP address.
By default, connection are kept opened in haproxy side even if the
client has closed it. This is required because it's impossible for
haproxy to detect a full close or only a sending channel close. In the
last case, haproxy can still deliver the response and then fully close
the connection. This is conform to the default http specification and is
useful when dealing with clients tools such as netcat which rely heavily
on this behavior.
If all your clients are browsers and the traffic is enough to fill the
haproxy queue, it is useful to activate abortonclose. When a user hits
the "STOP" loading page of the browser, the connection is immediatly
close on haproxy, which liberate some resources to handle other
connections.
So to summary, this option should be activated if you only have browsers
as client and the traffic is big enough to saturate haproxy queues.
I hope this will clarify your thoughts,
--
Amaury Denoyelle
