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

    Hybrid SSL off load and not

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    4 Posts 2 Posters 507 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.
    • T
      Tony Soprano
      last edited by

      I need to SSL offload at frontend these urls:
      example1.com -> offload SSL using acme in pfsense -> backend1 in http
      example2.com -> offload SSL using acme in pfsense -> backend2 in http
      but
      example3.com -> http and https must direct to go backend3 because letsencrypt can handle and release certs into VM

      ATM i have a working config in haproxy frontend for only example1 and 2 like this:
      in order haproxy frontend i have:

      1. http redirect to https
      2. frontend for the 2 urls SSL offload with acme certs

      working. how to add my needs?
      Thanks for your help

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

        @Tony-Soprano
        First off, "HA" in this category stands for High Availability. HAproxy topics should be posted in https://forum.netgate.com/category/52/cache-proxy, however.

        I need to SSL offload at frontend these urls:
        example1.com -> offload SSL using acme in pfsense -> backend1 in http
        example2.com -> offload SSL using acme in pfsense -> backend2 in http
        but
        example3.com -> http and https must direct to go backend3 because letsencrypt can handle and release certs into VM

        On a single IP/port combination you can only have a single frontend listening. And a frontend can either do SSL offloading or not.
        So if you do it for the one domain it has also be done for the either and hence you would need to SSL certificate on pfSense.

        Is there a good reason to handle the LE certificate on the backend?

        T 1 Reply Last reply Reply Quote 0
        • T
          Tony Soprano @viragomann
          last edited by

          @viragomann Hi tnx for your answer, yes a client has a magento installation which wont work after pfsens haproxy ssl offload.
          plus another client doesnt want to change domain provider but want to move its site on our MDC, but SSL comes into package of that domain provider and wont release one to us, client wont spend additional money to buy an external SSL.

          Ok we do have 2 public ips so if i config a second WAN on pfsense and make 2nd frontend answer to the second public IP, i can seti it as NON ssl offload for any domain into that frontend right?

          hmmm it's a waste of an IP. i'll think abt that
          Thanks

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

            @Tony-Soprano said in Hybrid SSL off load and not:

            yes a client has a magento installation which wont work after pfsens haproxy ssl offload.

            If the client just needs to do the SSL encryption for whatever reason (HAproxy should be able to satisfy the client / backend, so that SSL offloading should be doable), an option could be to assign a private certificate to backend web instance and install the certificate also on pfSense so that it trusts the backend, or simply disable SSL checks.

            You can also generate the backend certificate on pfSense with a local CA. The client cert can have a long period of validity.

            Ok we do have 2 public ips so if i config a second WAN on pfsense and make 2nd frontend answer to the second public IP, i can seti it as NON ssl offload for any domain into that frontend right?

            You can just assign additional IPs as virtual to the WAN interface and configure the additional frontend to listen on it. It has not to be on another interface.

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