Send-proxy-v2 passing through 0.0.0.0 to appserver?

Hi.

I have a send-proxy aware app running on an appserver which only allows tcp port access on 3336 from an haproxy box (I have tested this from my remote machine and unable to see the open port and the ip is listed below you are also free to try it). On the haproxy side I have firewall rules blocking a specific ip, yet I see periodically 0.0.0.0 show up on the app server log (there is nothing from the app server that would be hitting that port)

Ubuntu 16.04 LTS
HA-Proxy version 1.8.12-1ppa1~xenial 2018/06/27

See logs:

2018-10-22 09:33:15 [0.0.0.0] , x16r, no data
2018-10-22 09:32:46 [90.143.45.55] , x16r, no data

I am using mode tcp as follows:
global
        log /dev/log local0
        log /dev/lo local1 notice
         stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
         maxconn 32768
        nbproc 1
        nbthread 4
         log /dev/log   local0
         log /dev/log   local1 notice
#         stats socket /run/haproxy/admin.sock mode 660 level admin
         stats timeout 30s
         user haproxy
         group haproxy
         daemon

defaults
        log     global
        mode    tcp
        option  tcplog
        balance leastconn
        timeout client 99m
        timeout connect 60s
        timeout server 99m

frontend rvn
         bind *:3636
         default_backend stratum_rvn

backend stratum_rvn
     server rvn1 198.27.74.99:3636 send-proxy-v2
     server rvn2 198.27.74.99:3635 send-proxy-v2

I have also enabled the “usual” anti-spoofing rules using iptables:
-N spoofing
-I spoofing -j LOG --log-prefix “Spoofed source IP”
-I spoofing -j DROP
-A INPUT -s 255.0.0.0/8 -j spoofing
-A INPUT -s 0.0.0.8/8 -j spoofing

which have not helped.

Appreciate any insight how I can deal with this.

Could this be IPv6 (even a simple “curl localhost” on the haproxy could actually use IPv6 for transport, as localhost)?

When there is a mismatch between source and destination address-families, the proxy protocol may provide UNKNOWN instead.

If that’s not it, only a traffic capture between haproxy and your backend will shed more light on it.