Haproxy in transparent mode not working with Palo Alto


We are an educational setting, currently rolling out a new web filtering solution. We don’t want to have to configure all devices with proxy settings, instead we want to make this transparent to the user. I.e. with no proxy settings set – the Palo Alto firewall will pass traffic via Policy Based Routing to the filtering system which consists of 4 filter boxes. Therefore we understand we need an HAProxy server running as a load balancer and transparent proxy to do this.

Our setup:

Client subnet (
FILTER SERVERS (e.g.– device has gateway of

We have successfully configured an HAProxy server so that when the haproxy IP address is set in the web browser, we can browse the internet and be filtered appropriately. The filters successfully see the originating client IP to apply policies accordingly. However, as soon as the proxy settings are removed from the browser and we let the Firewall do the PBR, whilst traffic does hit the HAProxy server (seen by TCPDump) – it is not seen or handled by the HAProxy service. There are no entries in the haproxy logs. Do you have any suggestions as to what is wrong? I can confirm the client range and servers are on the same “zone” on the Palo Alto whilst on different subnets.

OS: Centos 6.7
Kernel: 2.6.32-573.12.1.el6.x86_64
HAProxy version: 1.5.4

Haproxy config file:

        log local2
        chroot /var/lib/haproxy
        user root
        group root

        log global
        option dontlognull
        timeout connect 5000
        timeout client 50000
        timeout server 50000

frontend filter_http
        bind transparent
        default_backend filter_app_http

backend filter_app_http
        mode http
        source usesrc clientip
        server filter1 check
        server filter2 check
        server filter3 check
        server filter4 check

Firewall and other routing config:

#  iptables -L -n -t mangle
target     prot opt source               destination
DIVERT     tcp  --             socket

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

target     prot opt source               destination

Chain DIVERT (1 references)
target     prot opt source               destination
MARK       all  --             MARK set 0x1
ACCEPT     all  --  

#  ip rule show
0:      from all lookup local
32765:  from all fwmark 0x1 lookup 100
32766:  from all lookup main
32767:  from all lookup default

#ip route show table 100
local default dev lo  scope host

# netstat -lntp | grep 80
tcp 0 0* LISTEN 1391/haproxy

# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.ip_nonlocal_bind = 1


Have you had a look at this blog entry which explains you everything:


Hi Baptiste. I had indeed followed those instructions however have not had any luck. I am not sure if I am over complicating my situation. I need to do some more testing and will come back to you once I have more evidence of what works and what doesn’t. I do know that if we take the HAProxy out of the diagram above, and policy base route to one of the filter servers directly, this works as expected.


Any resolution followup available on this andy_uk23? I’m seeing a similar set of circumstances with a DansGuardian transparent proxy from a Palo Alto that works fine with our other firewall, but with the Palo Alto in place the packets show up in the tcpdump but proxy software never sees the traffic.

I’ve seen some iptables manipulation on the proxy recommended that may provide a solution, but that wasn’t required with the previous firewall so I’m not convinced why that would be needed now (and have technical reasons why in my particular environment I’d like to avoid going that route).

Thanks for any followup.


We found HAProxy did not suit our needs in the end. Due to time constraints we tested and quickly implemented Linux Virtual Server (LVS) Direct Routing instead to distribute the traffic across the filter servers. This is working perfectly for our situation. Hope this information is useful to others.