Lukas Tribus <li...@ltri.eu> wrote: > The application (haproxy) needs to know the original destination IP > address, however it does not know whether -j REDIRECT was used or not. > Because of this the application always queries SO_ORIGINAL_DST, and > this includes configurations without -j REDIRECT. > > Are you saying the behavior of SO_ORIGINAL_DST is undefined when not > used with -j REDIRECT and that this issue does not happen when -j > REDIRECT is actually used?
No, thats not what I said. Because OP provided a link that mentions TPROXY, I concluded OP was using TPROXY, so I pointed out that the error source can be completely avoided by not using SO_ORIGINAL_DST. As I said, SO_ORIGINAL_DST returns the dst address of the original direction *as seen by conntrack*. In case REDIRECT or DNAT was used, the address returned is the on-wire one, before DNAT rewrite took place. Therefore, SO_ORIGINAL_DST is only needed when REDIRECT or DNAT was used. If no DNAT rewrite takes place, sockaddr returned by accept or getsockname can be used directly and SO_ORIGINAL_DST isn't needed. The returned address should be identical to the one given by accept(). If SO_ORIGINAL_DST returns the reply, then conntrack picked up a reply packet as the first packet of the connection, so it believes originator is the responder and vice versa. One case where this can happen is when nf_conntrack_tcp_loose (mid-stream pickup) is enabled. This is not a haproxy bug. Only thing that haproxy could is to provide a knob to make it only use addresses returned by accept, rather than relying on SO_ORIGINAL_DST for those that use TPROXY to do MITM interception.
