Host headers in Zero Trust config file

we are successfully tunnelling to an IIS server and can get to Hello World and a blank IIS on Port 80. We have verified the yaml file and all seems fine with a catchall to 404. However when adding in a service to localhost:8080 we are getting a 400. Even though browsing locally works.

We are only trying this as we have a number of websites on that server that are using hostheaders to identity them, however we are not sure that Cloudflare respects that?

So entering service: also gets a 400.

I have 3 questions

  1. Does Cloudflare Zero Trust respect hostheaders or do we need to create localhost bindings on different ports?
  2. If it does respect hostheaders how to do you write that into the configuration file?
  3. Our sites also redirect for the logon page so when you browse it actually sends you to should this matter, or do we need to write this into the config file as well?

It should pass on the same host header you access it via (i.e You can override it though, via httpHostHeader: Ingress rules · Cloudflare Zero Trust docs

If your application is designed well and uses relative redirects, or redirects based on the host header, you’re fine. The only time there would be an issue is if the application was configured to think it was at and tried to redirect the user to that.

You probably also want to use over localhost:8080, as that could mean either IPv4 or IPv6 ::1, and your server may not be bound on both.

thanks I’ll give that a go but it isn’t entirely clear how you use the httphostheader in the documentation. As we are testing at the moment the hostheader we are accessing externally is different to the hostheader internally. Do you just add it under originrequest as below? So hostheader specifies the host header and originservername can specify the cert?

  • service:
    noTLSVerify: true

That looks right. A config like this (replaced with your example) works for me:

tunnel: <snip>
credentials-file: /root/.cloudflared/<snip>.json

  - hostname:
      noTLSVerify: true
  - service: http_status:404

ex. - - [08/Feb/2023 21:10:07] "GET / HTTP/1.1" 200 -

Just a side note, specifying both originServerName and NoTLSVerify is a bit redundant. originServerName is saying “accept the certificate with this common name” and noTLSVerify is “Accept Anything”

thank you yep it was the host header which fixed it

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.