Project

General

Profile

Bug #10937

HAProxy frontend and backend entry limit

Added by Marcos Mendoza about 1 month ago. Updated 29 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
haproxy
Target version:
-
Start date:
09/29/2020
Due date:
% Done:

0%

Estimated time:
Affected Version:
Affected Architecture:

Description

There seems to be some sort of limit in the number of entries/rows you can have in a single haproxy frontend or backend.

  • In backends, it shows an error after clicking save at 292 server rows. Error: The value " in field 'Client timeout' is not a number
  • In frontends, it shows an error after clicking save at 122 action rows with 1 ext address entry. Depending on the combination of entries(ext address entries, acl entries, action entries), the overall limit changes. Error: The field 'Strict-Transport-Security' is not empty or a number.

This is reproducible in 2.5.0, 2.4.5-p1, as well as haproxy and haproxy-devel packages.

Steps to reproduce:
  1. Start with a default configuration of haproxy-devel
  2. Click Add to create a front end; give it a name.
  3. Click the arrow to add an action; leave everything else as is.
  4. Click Save.
  5. Edit the new frontend and duplicate the action entry until there's a total of 121, then click save.
  6. Edit the new frontend and create 1 duplicate action entry and click save.
  7. Error appears.
error-backend.png (18.1 KB) error-backend.png error on backend page Marcos Mendoza, 09/29/2020 11:01 AM
error-frontend.png (15.4 KB) error-frontend.png error on frontend page Marcos Mendoza, 09/29/2020 11:01 AM
success [20-09-29 09-10-07].har (1.35 MB) success [20-09-29 09-10-07].har http archive from browser on successful save Marcos Mendoza, 09/29/2020 11:03 AM
fail [20-09-29 09-10-35].har (2.35 MB) fail [20-09-29 09-10-35].har http archive from browser on failed save Marcos Mendoza, 09/29/2020 11:03 AM

History

#2 Updated by Marcos Mendoza about 1 month ago

Making the following change then restarting php-fpm and webConfigurator (option 16 & 11 in console) resolved the issue:

In the file:

/etc/rc.php_ini_setup

Change:
max_input_vars = 5000

to:
max_input_vars = 50000

#3 Updated by Jim Pingle about 1 month ago

The input variable change is an OK workaround (I'm not sure why it's at 5000) but also the form code should probably be improved so that it only submits relevant variables. Somehow I doubt it should be submitting 5000 variables for only <= 300 entries.

This happened to ACME a while back, the same fix may apply here:

https://github.com/pfsense/FreeBSD-ports/commit/1b65abcd8cebda591eebe55aa7f77cef111e5685

#4 Updated by Marcos Mendoza 29 days ago

I looked for existing CVE's around increasing the limit, but did not find any issues with it. I would agree however that increasing the limit is not ideal and a more efficient form submission method should be implemented.

Also available in: Atom PDF