SSL with additional domain

Hey @gurbina93 this is pretty cool, thanks for this. I decided to buy a domain and migrate over to a cloudflare setup recently and stop using duckdns.

I was hoping you could answer a few questions though if you don’t mind. Cloudflare has a ton of options so was hoping to get help from someone that has it figured out.

  1. You said in your earlier post that Access is one of the big benefits but I’m not really sure if I get why. It seems like the purpose is to add an authentication layer to your app but my app already has an authentication layer. Other then the /webhooks URLs which can’t be locked down and the login screen, everything already requires authentication. So what does Access provide in this situation? The firewall I totally get, that’s great. But yea I’m confused what Access adds over that.
  2. In the Settings panel of Firewall there’s an option for Security level which can be set to Low, Medium or High and an option for Bot fight mode which can be turned on or off. Do you know what either of those do? I assume they are basically like OOTB firewall rules but its not really clear how they translate into firewall rules.
  3. Do you use the rate limiting feature? This is actually the feature i was most hoping for since it seems like a much better version of fail2ban. Sadly it isn’t free so I’m trying to determine how much it will actually cost. Wondering if there’s a way to ignore authenticated traffic since I really just want to rate limit the unauthenticated traffic and there’s far less of that.
  4. Do you use the caching or auto minimize features? I have them turned on right now to try them out but I feel like Lovelace UI doesn’t like that, I’ve seen a bit of wonky behavior where I have to refresh more then I used to and wondering if that’s the cause

[EDIT] Also let me know if you’d rather I PM you or put this on a different post. I know its kind of unrelated to the topic but it seemed like this topic had become mostly about how to use cloudflare at this point already so figured I’d just reply.

So…

  1. It’s 2 step factor authentication which will require access to whatever you link it (like your email, Facebook account, etc) to not just a single username and password, you can also have 2FA on HomeAssistant but I’d rather have people be stuck at Cloudflare Access portal than reaching my instance.
    I linked mine to my email address, Facebook and Google. So I can login with Facebook/Google on just 1 click, and as a fall back I have the email 2FA (since my workplace blocks Facebook for example or if the site goes down).
    Added advantages are:
    Visitors and bots don’t know what they are hitting, they will hit the Cloudflare portal.
    Even if you had 2FA in HomeAssistant and they can get to it they can already see it’s a HomeAssistant, PLEX, Nextcloud, etc instance and that’s info that can be used against you. So if bots don’t know what’s services are running on your domain since they hit the Cloudflare Access portal that’s a good thing, isn’t it? You won’t see your HomeAssistant showing up on Shodan or some other sites. And anyway I feel safer knowing they’re hitting, getting stuck or cracking Cloudflare servers and not mine.

Aditionally you can see whatever or whoever is trying to get in on the logs, you will see the IP address, the email or Facebook account linked, dates, state (allowed, blocked), authorization status, etc. You can revoke these active authorizations.
This gives me better control over who has access to my instances and who is using it, just a personal preference.

  1. It’s on the help button next to the options here’s what each one of these do:
  • Essentially off: Challenges only the most grievous offenders
  • Low: Challenges only the most threatening visitors
  • Medium: Challenges both moderate threat visitors and the most threatening visitors
  • High: Challenges all visitors that have exhibited threatening behavior within the last 14 days
  • I’m Under Attack!: Should only be used if your website is under a DDoS attack
    • Visitors will receive an interstitial page while we analyze their traffic and behavior to make sure they are a legitimate human visitor trying to access your website

I have mine on High, I never have issues accessing my instance. When I do I see some waiting page that says I have to wait 10 seconds like this one or even a proper challenge:

The one for the bots it’s to fight bots like the one from Shodan or any other bot scrapping the web/ports, even Google Assistant, Uptime Robot, etc are considered bots.
This is good personally I don’t wanna see my domain showing up there with whatever I am running if it got exposed like HomeAssistant, PLEX, NextCloud, Unifi, Tranmission, etc.

  1. Since I have my instance blocked with Cloudflare Access and strict Firewall rules I don’t see this necessary, it’s for family and friends use and not open to the public in general so I don’t see how rate limiting benefits me, they’re trusted clients which require authentication so I don’t see them as a threat trying to hit me like that.

  2. Standard caching but I haven’t seen any benefit, I am just running with defaults. The auto minify feature will break some functionalities in HomeAssistant, specially script related. I tried some of the others like Brotli (no issues there), HTTP2, Rocket Launch and others but they didn’t seem to help much or broke stuff. I haven’t tried any of these for over 16 months so not sure if they will work now.

Anyway take everything with a pinch of salt, this is just my personal views, I’m no expert on the field but it works for me and I have seen some major changes on the incoming traffic and IPS alerts I get.

For #1, I get what you mean about stopping people at the access page so they don’t know home assistant behind it, that does sound like a plus. My main concern though would then be all the HA communication that can’t handle this extra layer of authentication being injected.

Like as a human I can deal with two login screens. But then I assume I would need to let everything coming in over /api/* to bypass since any code trying to communicate with the API would not be able to handle this unless I could modify it to include a generated security token from Access, which I won’t be able to in most cases. And what about mobile apps, can they handle an extra layer of authentication injected in like this? Do you use the HA mobile app? You mentioned Plex, Plex has lots of apps for various devices that require login. Do they still work with cloudflare access in front of your Plex server?

For #2, let me clarify. You mentioned specific firewall rules earlier about blocking things with threat level >30. I was curious how those rules compare to the Security level setting, like if threat level is also what that looks at for who to block and challenge or other factors. And the other rule you mentioned was blocking all bots which sounds a lot like bot fight mode.

Anyway basically just trying to figure out if one or the other was redundant. Probably a question I’d have to ask cloudflare support though.

For #3, I was thinking rate limiting would be useful for preventing floods to your server. But yea I realize now that’s redundant if you have cloudflare access turned on, unauthenticated traffic never gets to your server in the first place.

For #4, thanks! I’ll turn off the auto minify options then and leave the others for now.

  1. Yes, you can let these services bypass the Firewall and Cloudflare Access. You can do it by whitelisting the providers IP or by URI, there’s also other ways to whitelist them or bypass them, there’s tons of filters for that. I can help you with the rules to get it sorted out.
    Cloudflare Access works great with the Ariela app and also the official HomeAssistant app on Android, I think I recall one guest using it on the iOS version and he had no issues. They’ll get a pop-up with the Cloudflare Access like accessing over a web browser followed by the HA sign-in page. Once you log in it will go back to the HomeAssistant app and work as usual, you only do this the first time you log in. The authorization token will remain active on the device unless you revoke it or set it to expire within certain period. For Nextcloud I think I do have issues with the mobile app as it tells me my server it’s malformed but works fine on the web browser. I actually I need to look into this, find a way to fix it.
    For PLEX it seems to be working fine.
    Seems like some of these apps will open a browser for authentication or are just an iframe or whatever you call them like web browser viewer inside the app so basically so no issues with Cloudflare. I think Nextcloud app uses native login so that’s why it doesn’t work with it. Haven’t found a way to get it fully working, I just tried something and got the Cloudflare Access to show up but now upon entering the code it takes me back to the apps and craps out with this error:

  2. That’s right, moreover you have the firewall too.

Ah ok, so its a bit of YMMV when it comes to apps, depends what they do. But good to know the android and iphone ones work, those were the most important to me. I’ll have to give it a shot.

This actually brings up another question I had, what is the recommended way of whitelisting a particular provider? If a provider uses a particular IP or range of IPs that seems like the best approach but for many of them its not really possible to narrow them down in that way.

I saw Cloudflare lets you filter on AR Number which seems better but a bit cloud service dependent. Google and Amazon definitely have designated AR numbers but many services don’t. Calls from Uptime Robot for instance have AS46475 LIMESTONENETWORKS which sounds like a shared service provider based on googling. So I wouldn’t want to use that for them.

Googling a bit the general recommendation seems to be to idenfity servies by the User-Agent field but those are easily spoofed by bots so I’m not sure how I feel about that. What do you use? Do you try and identify IPs when possible and just open specific routes otherwise or have you found a more universal solution here?

Well seems like you’re way ahead of me on this.

For me I just whitelist request by the URI for some like Google Assistant in the Firewall:
/API/google_assistant/

For Access I just apply it to the authorization path in cases where I did not have their IP or a workaround, not sure if bots will still be able to hit other places or gather info from them if you apply it to an specific page like the HomeAssistant login page under:
Yourhomeassistant.com/auth/authorize
Since it’s the default page for unauthorized users it kicks in just by reaching my domain, for authenticated users it will redirect them to /Lovelace/0 which is my default Lovelace view.
Due to this they might be able to reach other resources if they know the specific pages or resources. In this case for example Google Assistant (and anything else out there in the web), would have access to to /API/google_assistant/ path. But they would need to know what they’re looking for.

Another way is to get the IP ranges from the Cloudflare logs and whitelist them. For me Google Assistant have been using the same range of IPs for quite a long time but I have already been able to identify that range of IPs.

UPDATE:
Seems like you can disable Access for your Nextcloud, log in and authorize your device, then enable it back. It will keep working.
It seems like Nextcloud has some kind of an extra one time device authorization step when you use their app that doesn’t mix up well with Cloudflare Access, so you can temporarily disable it when you do this one time step.

1 Like

Ok cool thanks for the help I’ll give it a shot

@gurbina93 I think I have an idea. I don’t think I can put access in front of my main HA domain as is because it will frustrate my family. It looks like the max length of time you can give a session is a month which I take to mean every month everyone will need to reauthenticate in order to keep the app working. While I’m willing to do this, no one else will be. It will likely just result in the app stopping to work every month for everyone else and an inability for me to do presence detection until I fix phones.

So I think I’m going to try an approach similar to how HA does webhooks. I’ll have nice, single word subdomains for everything protected by access so its easy to remember and get to in the browser but still protected. But then for each site that I need to access with an app/bot I’ll have a second subdomain with a lengthy generated unique ID (like a webhook) that’s very difficult to guess and then isn’t protected by access, firewall only. Since they will only be used in places where the name is specifically stored as a setting and doesn’t need to be remembered or typed in this seems like a good compromise.

If you apply it to yourdomain.com/auth/authorize path only then Cloudflare Access will never be triggered as long as the HomeAssistant user session remains valid. That path is the HomeAssistant login.
This is because as long as you’re logged in you’ll not be redirected to that page unless you purposely navigate to it.
That page is only shown when you go to your domain and you’re not logged in, so for any stranger or new device/browser visiting your domain they will be redirect to yourdomain.com/auth/authorize and then this is when Cloudflare Access kicks in.

That solves your issue while still applying it. Does that make sense to you?

I’m looking in my Nginx Proxy Manager logs now though and when I open the HA app the first thing I is a call to {ha domain}/?external_auth=1. After that when I navigate around the app I see all the normal URLs (/lovelace/... URLs, /api/... URLs, etc.). So I guess if the app is never opened it might be ok and limited just to the /api/* and /auth/authorize urls but as soon as it is opened it seems like cloudflare would step in front once a month.

Also we all use the Bitwarden add-on as a password manager and Idk what URLs that one needs access to in order to work properly but it definitely can’t go down. Getting everyone to use a password manager used up all the annoyance tolerance they had for my attempts to secure our digital lives, I definitely can’t risk messing up that app for everyone. And everyone besides me cares about that app way more then the HA one tbh.

I think for now I’m going to go with it like this. If I start to see unexpected traffic on those other URLs then I’ll revisit the plan. Thanks for all the help though!

1 Like

Hi finally I a new domain (my provider hosting my prima domain is too lazy to change DNS to cloudflare, asked many times he is not doing it), and trying to do your setup. Problem is Nginx proxy manager has only the option of no certificate, or using Letencrypt certificate. How do you add cloudflare certificate to it?

EDIT, Ok I got it, adding in the SSL CERTIFICATES section of nginx proxy manager.

Do you use this “intermediate certificate”??? I just uploaded the .pem as CERTIFICATE and .key as CERTIFICATE KEY

Other small issue, I have another instance of HASSIO with motioneye.

I wish that when I go to camera.mydomain.com points to http://192.168.1.9:8123/a0d7b954_motioneye (I tried also taking out the port)

but this is not working (it is working camera.mydomain.com to http://192.168.19:8123

you do BYPASS or ALLOW?

the below ALLOW is not working
(http.request.uri contains “/api/google_assistant”)

EDIT, ok it works , you have to wait 60 seconds, then it works.

BTW how is the rule for UPTIME ROBOT?

So for the SSL certificate I will check and let you know later, since this is a one-off and I can’t recall. Either way it will only accept the certificates if you upload them correctly, so my guess is that you’ve done it correctly.
If you are able to set the switch to “Full (Strict)” under “SSL/TLS” in Cloudflare and set the proxy entry as HTTPS in NGINX Proxy Manager then you’re good to go, otherwise you will be unable to reach your instance to redirection and protocol errors or the proxy staying offline.

For MotionEye not sure I will be able to help as I no longer use it, but in the past I did with the same setup and no issues. This was before Ingress support was added to it. I will see if I can test it later on.

For UptimeRobot they have a list of the IPs and locations they use:


You can use the IP ranges in Cloudflare, set it as “Allow” for Cloudflare Firewall or as “Bypass” for Cloudflare Access.

Hi, if I set to FULL STRICT, and HTTP in proxy manager, it does work well;
if I change HTTP to HTTPS and save it jn proxy manager, and try to reload home assistant I receive ERROR 502 of cloudflare page

neverthelòess the unencrypted communication is only locally between nginx and the machine, no?

Sorry, my bad over there.
Actually you have it set correctly, what I meant is on the SSL tab for the proxy you need to force it and select your certificate in the first highlighted field which I guess you’ve done already.

(I grabbed this picture from the internet but you actually need to select your certificate)
image

Internet User <–(HTTPS)–> Cloudflare <–(HTTPS)–> Your NGINX Proxy Manager <–(HTTP/HTTPS)–> Your applications (i.e. HomeAssistant, MotionEye, etc)

*The underlined section is on your LAN

Of course it depends on the type of connection your apps are using, since you are using HTTP locally that’s why you get the errors. But anything over the internet is HTTPS.

Yes I do FORCE SSL and REQUEST a NEW SSL CERTIFICATE, I choose the one imported from CLoudflare.

(HTTP/HTTPS)– HTTP works (I can access HASSIO), HTTPS not.

By the way I also have a QNAP, which I can access locally at http://192.168.1.10:80
but when I use cloudflare correct CNAME, and NGINX P.M. with same settings as I use Home Assiatnt, it gives error also with HTTP. Have to investigate

Hi, please have a look at this. Is based on the new CaddyV2 proxy manager, and its pretty cool. I managed to proxy lots of servers and so easy. I think is a better solution instead of Nginx Proxy Manager

Now I am still missing Jitsi meet, but also Google Assistant is not working, not sure what to do

Not sure about caddy and others, they do work but I find them less user friendly, harder to setup.
I tried using them before but never got everything I wanted working. NGINX proxy manager has limitations since it’s mostly UI based (and whatever cannot via UI can’t be done or it’s a PITA), but it does what I want it to do and it just works.

For Google Assistant, you had it working before I suppose.

Jitsi is the piece in the puzzle you have to figure out, I think you just need to sit, relax, try to understand the logic of the setup required, read the requirements and limitations of each component.

I saw UDP ports are required for Jitsi, so you can have the website working through NGINX but you’ll have to forward the UDP ports directly to Jitsi (do not send forward them to the reverse proxy). So forward whatever ports like 10000-etc to the Jitsi proxy directly on the router configuration.

You also need to bypass the Cloudflare proxy for the Jitsi DNS record (the DNS record entry in the Cloudflare Console should be a gray cloud with an arrow instead of the orange cloud) as well since Cloudflare can’t proxy these UDP connections (same happens with other protocols like VPN).

I advise you to try that.

I’d just check the forums on what’s required or how to solve the issues when using reverse proxies with Jitsi. Maybe what I just told you will get you into the right direction.