Hi Stefan and thanks for your replies.
(Sorry for the late reply and replying to my own mail, I don't seem to
be receiving messages from the list after confirming the subscription
twice and noticed your replies when checking the archives.)
> when I understand you correct then you have forwarding enabled to that
> ports on pf.
>
> I had a similar issue on pfsense. The solution was to disable the
> forwarding to that port.
PF isn't doing anything special with the public IPs/ports that HAProxy
binds to, only allowing that traffic. PF does do outbound NAT for
internal servers to reach the Internet like so:
table <rfc1918> const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
nat pass on $pub_vlan from 10.10.15.0/24 to !<rfc1918> -> 1.2.3.4
Would a firewall be able to cause the HAProxy tproxy bind errors for
some (but not all) transparent connections? I believe firewalls could
block connections but shouldn't prevent the actual haproxy bind from
succeeding (?). I read through the code and see where the tproxy bind
error is being hit but unsure what is causing it to succeed sometimes
and fail others.
It doesn't seem like it would be an issue allocating or exhausting ports
since the original client IP+port is being reused with "usesrc client"
and there shouldn't be conflicts there. On FreeBSD there are no similar
sysctls to Linux's net.ipv4.ip_nonlocal_bind, and transparent does work
some of the time with my existing config until it starts failing.
> one another:
>
> source ipv4@ usesrc clientip
I have separate backends/frontends for IPv4 and IPv6 with "source
0.0.0.0 usesrc client" in defaults (also tried "clientip"), which in my
understanding should do the right thing for both v4 and v6 respectively.
Would there be something different about using ipv4@ here?
Any other thoughts to look at or data that would be helpful to collect?
