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

    Proper way to set up proxy forward for backend HAProxy server.

    Scheduled Pinned Locked Moved Cache/Proxy
    3 Posts 2 Posters 1.3k 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.
    • S
      SkippyTheMagnificent
      last edited by

      ok, so I understand the subject line might be a bit confusing, so I'll try to explain my scenario: I have pfSense+ 23.05 as my edge ingress point to a homelab. In the LAN side, I have a small kubernetes cluster with haproxy ingress. The kube haproxy uses host-headers to identify which pod to connect to inside the k8s cluster. Now, I want to expose a service running inside the cluster from outside of my local network. I can't seem to find the right backend configuration for the pfSense HAProxy service that will allow traffic through the pfSense haproxy to the k8s haproxy.

      More details: The K8S haproxy host uses letsencrypt certs for services running inside the cluster, AND similar certs to allow https ingress through the pfSense HAProxy as well, so, for example: https://ombi.mydomain.com redirects inside the cluster to ombi-service.media.svc.cluster.local:3456 (inside the cluster), and works successfully from any host on the LAN. So, I'm pretty sure that part is correct.
      However, when trying to access https://ombi.mydomain.com from outside my LAN, I get a 503 from the pfSense haproxy; most likely because all httpchecks are failing from the pfsense backend (Status page always shows the host offline).

      So, I think I've got something messed up in my "backend" HTTP check, somehow, but I'm struggling with how to configure it. I have this setup in my pfsense/haproxy backend config for this backend:
      613d5ac8-e960-4a9f-ba88-700d30e2c288-image.png f60f4b9b-3d27-43c6-a2eb-b798f8ec6eb9-image.png
      ff25bfe7-681a-41ac-b9c1-d72cde71be72-image.png
      in my backend rule, but no matter what I try, I keep getting an offline state for the HAProxy Ingress controller.

      I'm entirely sure I'm most likely doing something wrong, or missing a huge concept somewhere, so any tips/pointers/links to RTFM content, please feel free to let me know. Any suggestions? As mentioned, I CAN successfully get to other hosted devices/services OUTSIDE the k8s cluster from outside my LAN, so I know it works; I'm just having trouble routing to this one site/service inside my k8s cluster.

      Thanks in advance!
      Skippy

      1 Reply Last reply Reply Quote 0
      • S
        SkippyTheMagnificent
        last edited by

        I've been banging my head against a wall for a week... nothing seems to work. Internally (on my network), I CAN successfully navigate to https://ombi.mydomain.com and get a secure connection. As mentioned, I am doing host routing within the K8S cluster's HAProxy ingress, namely, if the host header is detected as "ombi.mydomain.com", it knows what pod/service to access inside the cluster. However, when going through pfSense haproxy, it 503's due to the detected host (k8s haproxy) not being able to verify the SSL cert: "Layer6 Invalid Response: SSL Handshake Error"

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

          @SkippyTheMagnificent
          First of all the backend state has to be online to get it work. If this isn't the case, the health checks might fail.

          You have enabled HTTP health check + SSL checks + "/" as URL to check.
          This means, HAproxy might try to access "https://10.0.1.160:443/" for checking the backends state. So the backend has to provide a valid SSL certificate for the CN "10.0.1.160". I'm in doubt...

          I'd switch the health check method to basic instead.

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