HA behind pfSense with Cloudflare

Configuration
1

Hi all,
So I had it working, for like 5 min… then did something and for the life of me couldn’t figure it out.
always ended with a 400: bad request.

eventually ended adding 0.0.0.0/0 as trusted proxy, which then allowed me to access the HA via browser on computer using my https://ha. url (registered with Cloudflare, and configured with reverse proxy)
(I hit my edge modem/router on 443: being forwarded inside onto my pfSense where I use ACME and HAProxy, the backend definition just points to my HA hostname:8123)

This enabled me from computer to access my HA via browser, however it’s not working from mobile device, it’s complaining about invalid certificate, and throwing the big red banner at the bottom.

G

2

Clouflare → Router → pfSense → HAProxy → HA

Some kind of network fetish? :grinning:

3

Clouflare → modem → pfSense → HAProxy → HA
I can’t remove the modem atm as my internet is ADSL based. I’m moving over to Fiber soon at which point I will go ISP into pfSense,

The modem atm is jsut that, pretty much jsut a modem and doing a NAT of outside 443 onto WAN port of pfSense:443

G

4

Point is: If you already have cloudflare in front, what’s the point of pfSense?
I assume here that cloudlare does the SSL termination…

5

pfSense is my local Router/FW, runs on prem DHCP etc.
(it’s the hot where haProxy and ACME certs are hosted)

G

6

maybe something to add, I got it working on a iPad also through a browser, it’s through the iOS app that it’s refusing.

G

7

Never mind thinking it was working, it just started with always ended with a 400: bad request.
on browser also.

back to drawing board.

— ok, got it working again it did not like me trying to clean up trusted_proxies, back to the 0.0.0.0/0
ha is accessible via my external DNS through 443.
interesting enough, HA app open MAC - works, Mobile apps on phone, not.

G

8

works for like 10-15min via browser and then goes error 400.

FFS… this is madness.

G

9

It should be absolutely no different for the configuration whether it is going through cloudflare or not. use_x_forwarded_for: true must be present, and the trusted proxies must be present. In your case the trusted proxy is probably ONLY the pfsense router, HAProxy is probably already configured to only allow traffic from cloudflare IPs?

That said… there is still the question of why you are bothering with ACME on the domain, if Cloudflare is handling your SSL? It’s a bit over the top to have SSL from the browser to Cloudflare, then SSL from Cloudflare to pfSense - it’s introducing more points to fail.

Either let Cloudflare handle everything and use their massive block of IP addresses for the trusted proxy config. Or Have Cloudflare ‘bypass’ the domain and have pfSense handle the SSL. DO NOT do both.

10

its of little help if you have browser to Cloudflare encrypted and then clear text on port 80 from Cloudflare to router. that 2nd leg is most of the time more critical as thats where they come and look what you up to, thats your exposure point, opening port 80 on your FW.

this works perfectly with a web site, where I come in all the way into my pfSense on port 443, and then on the inside of my network I go port 80, or in HA case 8123

I will try and set my trusted proxy to the LAN address of my pfSense, lets see.

G

11

If you just look at your Home Assistant logs when you get a 400 bad request, it will have a line that says that it rejected a connection from an IP address (which it will tell you) which was not configured as a trusted proxy. So you will be able to figure out if it’s complaining about an internal IP address or an external one.

12

i’m bad at logs, where are these ?
let me look.

asking as Configuration : Logs is not showing anything

10.0.0.1 is the LAN IP on My Modem
10.0.0.2 is the WAN IP on the pgSense

G

Screen Shot 2021-10-16 at 15.10.41
Screen Shot 2021-10-16 at 15.10.411044×236 32.5 KB

13

Your trusted proxies should be:

trusted_proxies:
    - 10.9.116.254
    - 173.245.48.0/20
    - 103.21.244.0/22
    - 103.22.200.0/22
    - 103.31.4.0/22
    - 141.101.64.0/18
    - 108.162.192.0/18
    - 190.93.240.0/20
    - 188.114.96.0/20
    - 197.234.240.0/22
    - 198.41.128.0/17
    - 162.158.0.0/15
    - 104.16.0.0/12
    - 172.64.0.0/13
    - 131.0.72.0/22

With the top address being your HAProxy address.

Meanwhile your config in HAProxy needs to have:

http-request replace-value x-forwarded-for ^ "%[hdr(x-forwarded-for)], %[src]"

Because otherwise you will have multiple x_forwarded_for headers and Home Assistant will complain.

Github: https://github.com/home-assistant/core/issues/40421

14

any idea where this must be set ? I"m digging…
in front end there was the option to enable “Use “forwardfor” option” which I’ve now unticked.
still getting invalid certificate on mobile devices through, thinking there was 2 issues maybe, the 400 and the cert on mobile app on cell phone.

G

15

think I found something that might be pointing to the problem,
as it seems we got the browser based https stable.
the mobile works on a socket:

G

16

What is the certificate presented by cloudlfare?
If it’s the letsencrypt one, you might encounter an issue like Home assistant Android App and Let’s encrypt certificate - Mobile Apps - Home Assistant Community (home-assistant.io)

17

it’s the ACME generated lets_encrypt,
but the mobile app is iOS.
G

18

One of the replies mentioned iPad…

PS. BTW, using ACME in place of “certificate” or “Let’s Encrypt” is not correct. ACME is just the protocol used to obtain and renew the certificates with Letsencrypt.

19

Chris, true… but I also mentioned the ACME generates the lets_encrypt cert.

we’re a apple house, all the mobile devices are iOS.

Believe my problem is related to the web sockets, getting them working. looking for a clear explanation, what to enable how and where.

All I really want to work is the mobile device, happy to close web access to the HA site from outside.

G

20

If it would be so, the browsers wouldn’t work, either