Best practices - running multiple websites/services on the same cloudflared tunnel IPv4 & IPv6?

Hello,

I am experimenting a bit with Cloudflare Tunnel.

Furthermore, I wonder for example if I have a situation as below:

  • dedicated server with the installed web server (Nginx, 443 ssl http2) and working 10, 20, 50+ domains
  • all domains are behind and using Cloudflare service
  • all domains on Full (Strict) SSL each using Cloudflare Origin CA Certificate and Authenticated Origin Pulls
  • running a cloudflared as a service (on startup/boot)
  • added the route for IPv4 and IPv6 subnet ( cloudflared tunnel route ip show)
  • added a CNAME record(s) to each of the domains
  • all working fine for now “as-is”

May I ask what are some best practices in terms of running a cloudflared tunnel with multiple services / hostnames / domains as above stated (listed) conditions?

Should I run only one or “multiple instances”?, just in case if some connection fails - I even saw in the terminal that it retries immediately to some other closest available.

Or is it good way to split per some “category” or “priority” of domains, or like services as SSH to be a separate “ssh tunnel” one from the “websites tunnel” (even the different parameters could be added to each, but also in the same config/tunnel)?

I am not sure, but it would be a real mess in the config.yml file at least as it seems to me …

Nevertheless, when running cloudflared tunnel ingress validate, I got returned (eddited config.yml with nano editor - should I use some other?):

  • error parsing YAML in config file at /root/.cloudflared/config.yml: yaml: line 7: mapping values are not allowed in this context

config.yml:

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

ingress:
 - hostname: wordpress.domainB.com
   service: https://localhost:443
    originRequest:
      connectTimeout: 30s
      noTLSVerify: true
 - hostname: test.domainA.com
   service: https://localhost:443
    originRequest:
      connectTimeout: 30s
      noTLSVerify: true
 - service: http_status:404

It does not throw that warning/error if I move the part from below:

    originRequest:
      connectTimeout: 30s
      noTLSVerify: true

And put it right after credentials-file, therefore remove for each service to get the final looking as below:

tunnel: <UUID>
credentials-file: /root/.cloudflared/<UUID>.json
originRequest:
  connectTimeout: 30s
  noTLSVerify: true

ingress:
 - hostname: wordpress.domainB.com
   service: https://localhost:443
 - hostname: test.domainA.com
   service: https://localhost:443
 - service: http_status:404

Result:

Validating rules from /root/.cloudflared/config.yml
OK

In above tunnel I could also combine and add the ssh like - which works:

 - hostname: "ssh.mydomain.com"
   service: ssh://localhost:22

But again, aren’t that all gonna be too much of the stuff onto the only one cloudflared tunnel?

Despite the fact of the documentation for IPv4 iptables of OS-Level-Firewall, may I ask if it is also a good way lock and secure IPv6 (ip6tables too) so far?

Some helpful information I have found, but still better to ask here:

I’m curious about this part. I’ve never done any routing for my tunnel(s). Docs make it look like DNS entries, which I do manually.

I use ‘vi’ (been using it for decades and I’m not going to change now)
My originRequest lines up with the service above it:
Screen Shot 2021-10-28 at 8.42.32 PM

I don’t think it’s too much stuff. I have 28 hostname entries in mine. I wouldn’t separate them out. Sure, if I break one that config, it all goes down, but if I get it right, everything works. No need to run multiple configs, multiple tunnels, multiple services, and I don’t have to keep track of which CNAME goes where.

2 Likes

That’s the word - it has to line up!
I editted it and run the validation - result is OK.
Seems I have added the two spare spaces before, obviously not needed (level nesting thing) :smiley:

Cool to know.
Agree.
Great!

Yes, that’s understanding :smiley:

Thank you!

1 Like

I think you need to add this to your Config if you are using routing

warp-routing:
  enabled: true

I use routing to connect to ssh using private ip and it works without any problems even if using the smae tunnel to connect with the multiple website.

1 Like

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