How To Guide For HAProxy and Let's Encrypt on pfSense: Detailed Steps for Setting Up Reverse Proxy [YouTube Release]

Additional Resources:

Connecting With Us

Lawrence Systems Shirts and Swag



Amazon Affiliate Store
:shopping_cart: Lawrence Systems's Amazon Page

All Of Our Affiliates that help us out and can get you discounts!

Gear we use on Kit
:shopping_cart: Kit

Use OfferCode LTSERVICES to get 10% off your order at
:shopping_cart: Tech Supply Direct - Refurbished Tech at Unbeatable Prices

Digital Ocean Offer Code
:shopping_cart: DigitalOcean | Cloud Hosting for Builders

HostiFi UniFi Cloud Hosting Service
:shopping_cart: HostiFi - UniFi Cloud Hosting

Protect you privacy with a VPN from Private Internet Access
:shopping_cart: Buy VPN with Credit Card or PayPal | Private Internet Access

:moneybag: lawrencesystems | creating Tech Tutorials & Reviews | Patreon

:stopwatch:Time Stamps :stopwatch:
00:00 :arrow_forward: HAProxy on pfsense
00:00 :arrow_forward: How The HAProxy Reverse Proxy Works
06:46 :arrow_forward: pfsene packages and WebConfigurator settings
07:28 :arrow_forward: ACME Let’s Encrypt Setup
10:40 :arrow_forward: Setting Up HAProxy General Settings
11:47 :arrow_forward: Creating HAProxy Backend
12:50 :arrow_forward: Creating HAProxy Frontend
14:45 :arrow_forward: DNS Settings & Host Override Setup

#pfsense #firewall #networking

Hi. When I try this I get nxdomain on truenas in dig. When I use dig on my main domain it works and the ip is reported. I don’t understand why? I followed the video to the letter. Also, I saw in your video that you use the default webconfigurator and not letsencrypt cert in advanced? Can you do that and still have it work?

I am not fully clear on what your question is but if TrueNAS reports a different DNS response than your other system then you probably do not have TrueNAS using the pfsense as your DNS.

Ok. sorry. I explained badly. This is the result I get when I try to resolve dns (**** is instead of my domain):

root@rock-4se:/# dig truenas.****

; <<>> DiG 9.16.42-Debian <<>> truenas.****
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44659
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3c509286ddc61c140100000064dc955fd9b2fe32e8b0ed54 (good)
;truenas.**** IN A

**** 551 IN SOA 2023081501 28800 7200 604800 600

;; Query time: 30 msec
;; WHEN: Wed Aug 16 09:22:39 UTC 2023
;; MSG SIZE rcvd: 154

But I can resolve the domain itself. If I dig **** it reports my external ip so letsencrypt works. So I don’t understand why dns isn’t working? I know dns is like magic and I must know the right spells so I’m wondering if you have anything off the top of your head that feels obvious that I’ve done wrong or how I can troubleshoot?

You need a separate DNS entry for truenas.**** You can’t just point **** to an IP and have all the somethings.**** go there.

thank you for the respons. I gonna keep working on it. I have a feeling I wanna do more then my knowledge allows. I did add the truenas in dns resolver host override so I think I must have screwed up somewhere. I’m gonna keep at it. Thanks.


I just saw your video but… my isp gives me a dynamic ipv4, but instead it gives me a static /56 ipv6 prefix. Can I use that instead?

Not sure, I don’t use IPV6.

Hey @LTS_Tom, First let me start off by saying Thank You! Your YouTube channel has provided me the confidence to truly embrace the learning process with pfSense. Although I’m still learning and just scratching the surface with most things, not only have I started a home lab journey but I’ve been able to support my team at work with architecting, deploying and supporting a test environment that we use to build complex software integrations for commercial building automation. It spans 3 offices now! And I’m the sales guy :wink:

That said, I’ve been stumped…. I built 3 HAProxy FrontEnds on my home lab pfSense. Two of them use the same WildCard Cert. One listens on WAN port 443, another on the LAN port 443. The last one is a port 80 redirect that listens on WAN and LAN port 80 and only modifies the scheme to https.

Here is where things get weird. This setup was stable for 6mo maybe a year. Recently, like a week or so ago, some local PCs in my house that use the DNS overrides for the internal sites are using the WAN port 443 instead. I get a 503 error because the BackEnds don’t exist on WAN. So, naturally in my testing, I disabled both the port 80 redirect and the WAN Front End to which on the failing PC, I get a TimeOut error. So… I thought to myself, why would it all the sudden stop listening on LAN 443. I’ve completely reinstalled pfSense and created separate certs now in my attempts but whatever I do, some PCs (Windows 11 and macOS) fail to use the LAN port even though the DNS Overrides exist and work on at least one PC.

Could it be something wrong with DNS or is it that you shouldn’t use the same wild card cert on WAN and LAN??

The only other tidbit of trouble shooting I have is that the log on GrayLog shows some handshake errors but also shows that it’s coming from the WAN side.

Maybe a DNS flush on the client PCs?

Thoughts? Anyone one else run into this weird one?

One other thought I had was to change my wild card cert from * to two


That way the OS won’t cache the wrong addresses, think it knows where to go and fail to request the DNS Override entry???

Okay… So buit more information.

Here is an nslookup from one of the Windows PC’s that’s failing:

PS C:\Users\Pogo> nslookup -debug
Got answer:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:, type = PTR, class = IN
        name = pfSense.branya.lan
        ttl = 3600 (1 hour)

Server:  pfSense.branya.lan

Got answer:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:, type = A, class = IN
        internet address = XXX.XXX.XXX.XXX [PUBLIC IP ADDRESS]
        ttl = 971 (16 mins 11 secs)

Non-authoritative answer:
Got answer:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:, type = AAAA, class = IN
        ttl = 827 (13 mins 47 secs)
        primary name server =
        responsible mail addr =
        serial  = 1699331276
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 1800 (30 mins)


PS C:\Users\Pogo>

And here is an nslookup from a linux machine that directs properly:

pogo@dockerhub:~$ nslookup -debug

    QUESTIONS:, type = A, class = IN
        internet address =
        ttl = 3600
    QUESTIONS:, type = AAAA, class = IN


Let me know if there is a log or something more that I can provide. (I’ve done DNS flushing everywhere to see if that helped. It didn’t.)

I would check the the a browser update does not have them them using DOH instead of local DNS.

Wholly crap!!! It worked!! THANK YOU!!!

Is it a thing to turn on DNS-Over-HTTPS for pfSense and HAProxy so that it can work with encryption? Or is that not something that a person does for internal sites? It seams that there is an option for it in the DNS Resolver settings on pfSense but I’m assuming that it would conflict with HAProxy listening on the same port? If nothing else, at least I know what to do if another browser doesn’t connect. I’ll check that setting.

It took me a very long time to get to the point where I was able to write the post on your forum because I did so much trouble shooting… I really hope this helps others in my position in the future!

Thanks again Tom!

1 Like

I just finished some additional testing. And I’m curious what the danger is of doing the following:

I can confirm that simply ticking the Respond to incoming SSL/TLS queries from local makes it so that you can leave the DoH setting on and the it the resolver starts to work localy. Maybe it’s as simple as that?

DNS-Over-HTTPS works over HTTPS but I think the browsers check local DNS if they fail to resolve and entry, either way I recommend turning DOH off.

Hello there,

I get this thrown at my face when trying to “Apply Changes” after saving my frontend.

×Errors found while starting haproxy
[NOTICE] (684) : haproxy version is 2.7.8-58c657f
[NOTICE] (684) : path to executable is /usr/local/sbin/haproxy
[ALERT] (684) : config : parsing [/var/etc/haproxy_test/haproxy.cfg:15] : 'bind (WAN-IP):443' in section 'frontend' : 'crt-list' : unable to load certificate from file '/var/etc/haproxy_test/pfsense.pem': no start line.
[ALERT] (684) : config : Error(s) found in configuration file : /var/etc/haproxy_test/haproxy.cfg
[ALERT] (684) : config : Fatal errors found in configuration.

Any ideas? I followed everything nicely step by step…

I am guessing broken certificate