IPSEC and Haproxy on the FW – servers on the other side of the tunnel

enealDC

Hoping to get some help to make this work.
I have haproxy running on a FW which also has a site-to-site vpn to different facility where I have servers that I'd like to send traffic to. Unfortunately, I can't get my pfsense server to route the traffic to the servers I'm targeting over the vpn tunnel.
I've tried the suggestion here:

http://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F

But alas, this doesn't work for me.

Any additional thoughts?

jimp

How exactly do you have your site-to-site VPN setup?

The usual problem with trying to direct such traffic across a VPN is that the far side, where the servers are, will direct the replies back out the WAN and not back across the VPN.

You can use packet captures along the path to confirm how the traffic is (or is not) flowing.

jimp

Another possibility is the traffic source, the route should have nudged that in the right direction though.

The HAproxy process will make the connection to the backend server directly, but the source would be whatever route is 'closest' to the target network.

I suppose the real question is if you're using IPsec or OpenVPN

enealDC

Thanks for the reply.
I'm using IPSEC between a PfSense "box" (Site A) and an ASA (Site B). I have haproxy running on the box in Site A and I'm trying to get it to load balance to backend servers in Site B over the IPSEC tunnel.
Since both devices are the default gateway for both sites, I'm pretty sure that the routing is sound. I suspect that the pfSense box is not routing the traffic over the VPN. This is because I'm using non-standard ports on the backend server which would not be accessible from the WAN side.

jimp

It probably has more to do with how the HAproxy instance is sourcing the traffic that is trying to reach the servers.

If the proxy process using the "wrong" IP to send the traffic to the server, it would never enter the tunnel because it wouldn't match the Phase 2 entry on the tunnel.

Try redirecting temporarily to a local server, see how the traffic is sourced, and account for that in the IPsec Phase 2 configuration.