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

    HAProxy + Wireguard + Transparent ClientIP

    Scheduled Pinned Locked Moved Cache/Proxy
    8 Posts 2 Posters 921 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.
    • N
      nalle_j
      last edited by

      I have a HAProxy backend with two servers, one of them is on the other side of a Wireguard tunnel (pfSense on both ends). This setup is working fine, but if I enable "Transparent ClientIP", client traffic no longer reaches the server on the other side of the tunnel (funny thing is the HAProxy health checks are still working fine for both servers). I suspect this is a routing problem, but I have no idea where to begin?

      Please help :)

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @nalle_j
        last edited by

        @nalle_j
        A reverse proxy in transparent mode is a pretty terrible hack.
        What's the reason for using it?

        I'd rather let HAproxy add the x-forwarded-for header. So you can see and treat the client IPs on the backend as well.

        N 1 Reply Last reply Reply Quote 0
        • N
          nalle_j @viragomann
          last edited by

          @viragomann My servers are SFTP-servers, not HTTP. The SFTP servers have config for allowed IPs per user.

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @nalle_j
            last edited by

            @nalle_j
            I see. So let's resolve the routing issue.
            Probably the remote site is sending response packets out to its default gateway due to missing reply-to.

            To get this work properly you only need to make changes on the remote (backend) site.
            You have to assign an interface to the Wireguard instance in Interfaces > Assignments and enable it and enter a friendly name.
            This brings up a new firewall rules tab for this interface.

            Go to the Wireguard tab edit the pass rule and change the interface to the new one.

            Ensure that there is no pass rule on the Wireguard tab matching the forwarded traffic from the remote site.

            This assumes, that this is the only Wireguard instance. If you have multiple, also assign interfaces the the others and define the needed rules there.

            N 1 Reply Last reply Reply Quote 0
            • N
              nalle_j @viragomann
              last edited by

              @viragomann
              I have two Wireguard instances on each end, one for the site-to-site tunnel and one for management (myself). Both have interfaces assigned and both have a simple "allow any" firewall rule, example below for the remote site-to-site interface:

              91b13f06-924f-49c8-bcbf-2d0794e8fb5f-image.png

              I'm not sure I follow what you mean with "Ensure that there is no pass rule on the Wireguard tab matching the forwarded traffic from the remote site." How would that help my situation?

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @nalle_j
                last edited by

                @nalle_j
                So just remove all pass rules from the Wireguard tab. Since you have your rules on the interface tabs anyway, you don't need any on the Wireguard tab.

                N 1 Reply Last reply Reply Quote 0
                • N
                  nalle_j @viragomann
                  last edited by

                  @viragomann
                  Wireguard tab is all empty:

                  ea84e10b-9afd-41fe-94a9-3e6c9e14bc80-image.png

                  V 1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @nalle_j
                    last edited by

                    @nalle_j
                    So you have to investigate, what's going wrong.

                    I assume, that the packets reach the remote backend server, since the health check succeed, as you wrote.

                    To get sure, sniff the traffic at the remote site. First on the server-facing interface. If you can see requests and responses either, sniff on the Wireguard interface, and if there are no responses, sniff on the WAN to see if the packets go out to the default gateway.

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