Just some questions

[xd003]

Hello,
Thanks to your blog and resources, I'm nearly done finalizing my Traefik setup, I really appreciate the guidance so far. I just have a few remaining clarifications before I wrap things up

1. Cloudflare Tunnel vs Open Ports
   I noticed that you’re using Cloudflare Tunnels for your external Traefik instance. I considered the same approach for my VPS, but I also run services like Jellyfin, which are restricted from being proxied through Cloudflare Tunnels. Since Jellyfin will require me to expose ports 80 and 443 anyway, does it still make sense to use Cloudflare Tunnel for the rest of my services?
   I'm inclined to skip the tunnel and use a standard reverse proxy for everything to avoid the extra hop and overhead, especially since I’m already opening the required ports.

2. Single vs Split Traefik Instances
   Assuming I go with the typical web and websecure entrypoints and forego Cloudflare Tunnels entirely, is there any practical reason to maintain separate internal and external Traefik instances? I’m wondering if I can simplify the architecture in this case.

3. Middleware Structure (Authelia, CrowdSec, Secure Headers)
   I use Authelia for authentication and enable its middleware selectively via Docker labels on specific routers. I’m also using your secure-headers middleware. How should I structure the middleware chain to ensure that:

   • CrowdSec and secure-headers are applied consistently to all requests, and
   • Authelia is applied last

For reference, here are my static and dynamic Traefik configuration files.

[FoxxMD]

Cloudflare Tunnel vs Open Ports

The main benefits of using CF tunnels are

• circumvent CGNAT (not applicable to your scenario)
• benefit from CF proxying IE
  • protection against ddos, get basic WAF, block ai scraping, etc...
  • hide your own IP behind CF

That second set of benefits can also be achieved using only fully proxied DNS records instead of CF tunnels. The same restrictions to traffic still apply to that usage though, so for jellyfin you'd still need open ports.

However, you could still gain a partial benefit by using separate domains for these these two sets of services IE

• run all non-streaming, public facing services through domaina.com that is fully proxied by CF
• run jellyfin on open ports through domainb.com

Assuming your domain registration for both uses privacy protection (the default) no attackers would be able to make the connection both domains are owned and hosted by you. So...any attacker looking at your non-streaming services would still have to contend with CF without knowing they can "bypass" by hitting your open ports since they wouldn't know your real IP or that the domains are associated.

Of course this won't stop any random IP port scanning but it would certainly thwart targeted attacks aimed at non-jellyfin services.

This would be a scenario for keeping CF, at least partially. But it's also your call and your risk assessment to make!

If you do go with open ports I would consider installing crowdsec's firewall bouncer (or try this dockerized version) on the machine the open ports are forwarded to.

Single vs Split Traefik Instances

Certainly, the architecture can be simplified. I originally started with only one traefik instance.

The point of having two instances is that each instance (and all the services proxied by that instance using an overlay network) is on a separate docker network which comes with a bunch of benefits for networking security:

• By default, containers on different docker networks cannot communicate with each other
  • So out-of-the-box your public-facing stacks cannot communicate with internal stacks, preventing a compromised external container from accessing "less secure" containers you may be running with internal-only security postures
• Separate networks get distinct subnets which means Level 3 (packet-level) firewalling with iptables is possible
  • I have iptables rules on each host that drops any NEW state traffic from subnet 10.99.0.0/24 (public docker network) destined to terminate on my LAN subnet 192.168.0.0/24 -- so no containers on the public network can autonomously make new, outgoing connections to my LAN (which is what an attacker would want to do)
  • this doesn't prevent any communication i initiate, though, since it's programmed to allow ESTABLISHED from anywhere :)
• trafficjam enables me to automate isolating traffic between stacks on the same docker network
  • This is further security for thwarting access from a compromised public container since an attacker would only be able to access containers within the same stack

You lose all of these benefits for stricter network security if internal and external are combined on one subnet. You could apply the policy to the combined subnet but then you're treating your internal services with the same strictness as external. Tools like n8n and uptime-kuma wouldn't be able to interact with IP's outside of the docker network.

One other caveat on all of this...you could still have separate networks for each set of services proxied by traefik, but then have traefik joined on both networks so there is only one traefik instance. My reasoning against doing this is that traefik becomes a single point of failure...I believe traefik is pretty battle-tested, security-wise, but fundamentally the security design is weaker since a vulnerability in traefik could potentially allow an attacker access to either network. Having gone to the effort of designing separate networks with all the above it makes more sense (IMO) to fully separate the networks and eliminate the potential failure point.

(I have a future blog post in the works to cover the above stuff)

Middleware Order

I believe that the order of application is like this:

• middleware, in order defined, found in entryPoints
• then, middleware in router dynamic config (like labels or file)

If you need to define mutliple middleware within a dynamic config use the chain middleware in which case the order applied is the order they are listed within the chain (and these come after middleware from entrypoint)

[xd003]

Thanks a lot for the detailed response, it really helped clarify quite a few things.

Cloudflare Tunnel vs Open Ports

If I’m using both streaming and non-streaming services under the same domain (e.g., jellyfin.domainA.com and other-services.domainA.com), is there still a compelling reason to use Cloudflare Tunnels?

I understand that Cloudflare restricts tunnels for certain streaming platforms like Jellyfin, so I’d likely need to handle streaming services through traditional port forwarding (e.g., 443), and non-streaming services via the tunnel.

In such a hybrid setup, I assume I’d need to:

• Define a new entry point specifically for the Cloudflare Tunnel. So i will be having 3 entrypoints at this point.
• Explicitly assign the correct entry point in Docker labels e.g., use websecure for Jellyfin, and the CF Tunnel entry point for other services.

Thanks again for pointing out the need to add the CrowdSec firewall bouncer — I’ll definitely be integrating that.

=================================================

Single vs Split Traefik Instances

Currently, I don’t have anything deployed on my home network, so I don’t need an internal/external split setup just yet. But knowing the rationale behind it helps — especially as I plan ahead.

One of the reasons I’m considering setting up the Cloudflare Tunnel now is to make future access to CGNAT-bound home services easier, without needing to revisit the Traefik setup later.

Looking forward to your future blog post on this topic — especially the part about firewalls and iptables, since I’ve never used those and will need to get up to speed.

================================================

Middleware Chain & Order

Just to confirm my understanding: to consistently apply CrowdSec and secure-headers to all requests, I should attach a middleware chain directly to the entry point in the dynamic config like this:

http:
  middlewares:
    chain-secure:
      chain:
        middlewares:
          - crowdsec
          - secure-headers

And in the static config:

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
          permanent: true

  websecure:
    address: :443
    asDefault: true
    http:
      middlewares:
        - "chain-secure@file"

Now, I have two follow-up questions:
a) Middleware Order
In the middleware chain, should crowdsec come before or after secure-headers? I’m not entirely sure what impact the order has or how to decide it technically. Edit - Just for completeness, lets just add rate-limit middleware to this ( i see many people using it although i am unsure if its really needed if we are already using crowdsec)

b) Middleware on web EntryPoint?
Should I apply the chain-secure middleware (or at least crowdsec) on the web entry point as well?
There seem to be two schools of thought:

• One says it’s unnecessary, since all traffic is immediately redirected to websecure.
• The other suggests adding at least crowdsec to web for early threat mitigation — while skipping secure-headers, since those are only relevant on secure (HTTPS) connections.

[FoxxMD]

is there still a compelling reason to use Cloudflare Tunnels?

It's really up to you...I still think having some CF protection is better than none. You mention setting up tunnels for future CGNAT config which is a good reason to keep it. If not tunnels, specifically, then at least keeping your wildcard subdomain fully proxied means you still get all those benefits (WAF, ai scraping, bot protection, etc...) for free on the non-streaming subdomains. I think you could set dns records like:

• YourIP A record => dns only
• jellyfin CNAME record => dns only
• * CNAME record => fully proxied

I'm not sure the same can be done with CF tunnels, though. Rather than having one wildcard entry in the tunnel config (for a normal setup fully covered by tunnels) you'd need to create an explicit "Public hostname" entry for each subdomain that needs to go through the tunnel.

In such a hybrid setup...

This is correct but you can define a default entrypoint, using asDefault , to reduce boilerplate. You'd set cf entrypoint as default and then only need to define entrypoint on the jellyfin label to use websecure instead of cf (assuming it was the only service using that entrypoint).

middleware chain

Your chain middleware syntax is correct BUT a chain is only necessary for dynamic configs like docker labels. In the entrypoints config in the static config you can just define a list of middleware that will be applied in the order you define them.

entryPoints:
 # ...

  websecure:
    address: :443
    asDefault: true
    http:
      middlewares:
        - crowdsec@file
        - security-headers@file
        - rate-limit@file

Those middleware will be applied to every route that goes through websecure in the order crowdsec, security-header, rate-limit.

In the middleware chain, should crowdsec come before or after secure-headers?

I don't think it matters. The headers being applied are for the benefit of the proxied application and since they are constant I don't think you'll ever have a scenario in crowdsec that uses them for detection.

What does matter, though, for crowdsec + cloudflare tunnels or cloudflare proxied dns is using and applying cloudflarewarp middleware before crowdsec middleware. Without this middleware crowdsec will always see the request origin IP as either the cloudflare tunnel container IP (private docker 172.xxx... IP) or one of the cloudflare origin server IPs, rather than the real IP of the request. That will cause issues with false detection and make crowdsec basically useless.

Should I apply the chain-secure middleware (or at least crowdsec) on the web entry point as well?

I haven't done this, don't think it really matters. I'm in the first camp. Unless you are doing a ton of traffic then you won't really save much performance by using crowdsec on web.

---

Also, IMO, it's best practice to append the provider namespace when using middleware.

• If the middleware is defined in a dynamic config file then it should be append with @file
• If its created in a label discovered by docker (not traefik-kop) then append with @docker
• If its created by a label discovered by traefik-kop then append @redis

If no namespace is appended I think traefik assumes the namespace is the same as where the middleware is found. Which means if you define a middleware foo in dynamic config file and then try to use it in a docker label like traefik.http.routers.my-container.middlewares=foo it'll assume foo@docker when it should be foo@file and you'll get config errors.

[xd003]

Thanks again for all your help! Just to wrap things up — if the cloudflarewarp middleware is applied as the first middleware on the websecure entrypoint (for a non-tunneled, non-proxied service like Jellyfin), it shouldn't cause any issues, right? I assume the plugin is smart enough to handle such cases gracefully.

Also, while defining the cloudflarewarp plugin, why are you adding the trustip option here. Their readme states that if disableDefault is set to false then trustip is not needed. Edit - i noticed that you have used it in 3 places.

1. traefik cf entrypoint (static), 2) cloudflarewarp middleware (dynamic), 3) csbouncer middleware (dynamic). I wonder what's the use case for this and if i need it in my setup too

Additionally if i am understanding everything correctly, if i am just using cf dns proxy then a new cf entrypoint isn't needed in traefik right, i can just route everything through websecure as default ?

Lastly, I think you’d really enjoy using DockFlare. It leverages Docker label syntax to create Cloudflare Tunnels via the API, so there's no need to interact with the Cloudflare dashboard manually. Definitely worth checking out!

[xd003]

@FoxxMD Hey, just wanted to check in, my earlier message might’ve gotten lost in the mix. Whenever you get a chance, could you take a look?

[FoxxMD]

Hey sorry! CF warp should stay out of the way if it doesn't find the CF IPs or CF-Connecting-IP header, yeah.

trustip

I found this was still needed to make forwarded headers work correctly, when using cf tunnels. Without it warp removes the CF-Connecting-IP header entirely (can be useful for some services to preserve it) and also adds the docker private IP to forwarded headers, which we don't want.

The CF entrypoint and warp should use the same ip/subnet specifying the subnet the cloudflared container is in EX

# traefik.yml
  cf:
    address: :808
    asDefault: true
    http:
     middlewares:
       - cloudflarewarp@file
       # ...
    forwardedHeaders:
      trustedIPs:
        - 172.28.0.1/24

# global.yml
http:
  middlewares:
    # ...
    cloudflarewarp:
      plugin:
        cloudflarewarp:
          disableDefault: false
          trustip: 172.28.0.1/24

But you may not need this if you are only using cf dns proxy. It should only be necessary if traffic is passing through another container before reaching traefik.

if i am just using cf dns proxy then a new cf entrypoint isn't needed in traefik right, i can just route everything through websecure as default ?

Technically yes but I think it's still good practice to have a separate entrypoint. Traefik serves api and dashboard on websecure as well and you don't want to accidentally leak that as a public route.

The key takeaway from my setup is that mixing public/private routing in traefik makes it very easy to accidentally configure a service for the wrong routing. The easiest way to prevent those kind of mistakes is to configure your system in a way that makes those mistakes fail by design.

As an example, if CF is its own entrypoint you can't accidentally copy-paste internal labels to an external service (oops wrong TLD!) because the external labels also requires traefik.http.routers.myservice.entrypoints: cf to get added to the routing.