HAProxy + CARP + use Client-IP = missing ipfw rules?

  • pfSense 2.4.4-p3
    HAProxy-devel 0.59_22

    While testing a configuration where CARP is present and when the backend is configured for "Use Client-IP" - selecting the inside interface that the web server uses for it's default route... The output from "ipfw list" is:

    65535 allow ip from any to any

    Would expect the rules to look something like:

    00010 fwd tcp from <server_a> 443 to any in recv <dmz-interface>
    00011 fwd tcp from <server_b> 443 to any in recv <dmz-interface>
    65535 allow ip from any to any

    The only logical difference appears to be the existence of CARP, although cannot authoritatively rule out other possibilities. Did try re-installing haproxy to see if that would have an effect and it appeared to make no difference. If the expected rules are manually added to IPFW, everything works as expected.


  • @justme2
    The webservers are configured with a 'IP' in the backend? Not a dns name?

  • Correct, they configured with "IP Address" (being an IP Address, not FQDN) and "Port". There is a short value in the "name" field for display purposes in the stats.

  • @justme2
    Do you have a captive-portal enabled on the same or any other nic? Can you check content of /tmp/ipfw_4000.haproxy.rules ?

  • No captive portal enabled. That file appears to contain all of the missing IPFW rules. Hmmm.... Where might one look to debug what is/isn't "firing" to install those rules?

  • @justme2
    Putting the file above and loading it happens the same php function..

    Can you try and run:
    /sbin/ipfw -q /tmp/ipfw_4000.haproxy.rules

  • @PiBa said in HAProxy + CARP + use Client-IP = missing ipfw rules?:

    /sbin/ipfw -q /tmp/ipfw_4000.haproxy.rules

    Appears that the lines use "localhost" - is causing failure vs. using "" (or IPv6 equivalent) to avoid any reliance on DNS or host resolution. localhost being unqualified (not an FQDN) would not resolve via standard DNS servers. It would work if /etc/hosts had a line item for localhost - although it's now reliant on resolution of the name to the IP Address, which if the hosts file isn't present with certain minimum entries - it would break the process down the road.

    Likely, should just be 'self contained' and use IP Addresses to avoid reliance on assumptions that may not be true.

  • @justme2
    Ah indeed with the proper configuration options localhost fails to provide a ipv4 ip.. i guess you've got at least the advanced unbound option enabled to not write localhost to the hosts file "Disable the automatically-added host entries".?.

    You can replace localhost in the haproxy.inc file at line 2239, that should fix it for now.. Thanks for reporting. Ill add it to my changes for next haproxy package.

  • Yes, you are correct in terms of the checkbox.


Log in to reply