Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved IPsec
    5 Posts 2 Posters 4.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • E
      enealDC
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • jimpJ
          jimp Rebel Alliance Developer Netgate
          last edited by

          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

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          1 Reply Last reply Reply Quote 0
          • E
            enealDC
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              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.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.