Issue routing trafffic from cloudflare to caddy

Help
1

1. Caddy version (caddy version):

2. How I run Caddy:

I am looking to setup caddy with cloudflare tunnel, so cloudflare tunnel passes traffic onto caddy, which then routes to IIS:

‘’’
tunnel: 32dbd6a0-bf5a-4ea9-a064-da8860fed91c
credentials-file: C:\Windows\System32\config\systemprofile.cloudflared\32dbd6a0-bf5a-4ea9-a064-da8860fed91c.json

ingress:

‘’’
My caddy file:

abc,def.com:443 {
reverse_proxy 192.168.3.129:443
}

tls abc@gmail.com

tls {
dns cloudflare {env.token}
}

log {
output file C:\caddy\req-access.log
}

}

I noticed that the log file does not get created, and I can’t acces the origin as I get a cloudflare bad gateway error. My intention is to pass traffic from the cloudflare tunnel to a local service (i.e. caddy).

a. System environment:

Windows server on server 2019

b. Command:

caddy run

c. Service/unit/compose file:

NA

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.



abc.def.com:443 {
reverse_proxy 192.168.3.129:443 
}
  
  tls abc@gmail.com

 tls {
   dns cloudflare {env.token}
 }
 
log {
    output file C:\caddy\req-access.log
  }

}

Paste config here, replacing this text.
Use caddy fmt to make it readable.
DO NOT REDACT anything except credentials.
LEAVE DOMAIN NAMES INTACT.
Make sure the backticks stay on their own lines.


### 3. The problem I'm having:
<!-- What are you trying to do, and what isn't working? Please describe the issue thoroughly enough so that anyone can reproduce the exact behavior you're seeing. Be as specific as possible. DO NOT USE WEB BROWSERS; use "curl -v" instead. -->

When browsing to the site, I get a bad gateway error.

### 4. Error messages and/or full log output:
<!-- Please **DO NOT REDACT** any information except credentials. Leave domain names intact! -->
<!-- Please **DO NOT POST TRUNCATED LOG LINES** as systemd is notorious for this. -->
<!-- Please **DO NOT USE WEB BROWSERS.** Use curl -v instead. -->
<!-- Please **DO ENABLE DEBUG MODE FIRST** by adding "debug" to the global options of your Caddyfile. -->


### 5. What I already tried:
<!-- Show us what effort you've put in to solving the problem. Be specific -- people are volunteering their time to help you! Low effort posts are not likely to get good answers! -->

I've spent most of my effort tweaking the caddyfile, but to no luck.

### 6. Links to relevant resources:
2

It’s a bit hard to grok with the formatting, but your CloudFlare tunnel config first stands out to me first. See their docs for defining ingresses. In particular, service needs to refer to the local host/port where Caddy is listening. By setting it to abc.def.com, it’s an endless loop back to Cloudflare’s edge.

If you’re running the Cloudflare tunnel daemon on the same host as Caddy, try something like this:

ingress:
- hostname: abc.def.com
  service: https://localhost
  originServerName: abc.def.com
- service: http_status:404
3

Ok i have got somewhere. At the moment cloudflare and caddy run on seperate servers.

My cloudfare config is below:

ingress:
  - hostname: 'abc.def.com'
    service: https://abc.def.com
    originRequest:
      noTLSverify: true
  - service: http_status:404

DNS for that domain resolves to the IP of the caddy server.

However, if I go to the site from the caddy server, I get this error:

wsarecv: The connection was forcibly closed by the remote host.

The web server (IIS) is running on https, so everything there is good. It would be good to fix that and then think about cloudflare.

4

Ok so between caddy > IIS, I can only get this to work by setting my reverse proxy and endpoints to be port 80 (i.e. no :443).

I enable experimental_http3 but I get the wsarecv error above. How is http3 enabled correctly?

5

Caddy’s reverse_proxy is HTTP by default; you need to turn on TLS by either using https:// as a scheme prefix for the upstream, or adding the tls option inside reverse_proxy.

Either way, you probably don’t need HTTPS between Caddy and IIS, because the connection is happening on the same device, right? There’s no benefit to HTTPS at that point unless you’re worried about software running on the same device being able to listen in on the traffic. HTTP here is simpler and probably slightly faster (avoids some overhead from TLS).

Only specify tls once:

tls abs@gmail.com {
	dns cloudflare {env.token}
}

Please run caddy fmt to clean up your Caddyfile’s syntax, it’s really hard to read with that messy indentation.

Also, your original post’s formatting is broken, making it really difficult to read. It would be great if you could fix that up.

Does Cloudflare Tunnels support UDP traffic? Probably not necessary anyways, since Cloudflare will do HTTP/3 at the edge.

1 Like
6

Ok so, a few things:

The network infrastructure is Cloudflare agent > caddy > web server(s). So Caddy and IIS are seperate servers. In the example caddy files I have shared, I have one backend but this will change as I will add more (just want to sort out the teething issues). I was also thinking that having the web servers handle ssl can be a performance penalty.

{
        debug
        servers :443 {
                protocol {
                        experimental_http3
                }
        }
}

https://abc.def.com:443 {
        tls abc@gmail.com {
                dns cloudflare xyz
        }

        reverse_proxy 192.168.3.129:443 {
                transport http {
                        keepalive 1s
                        tls_server_name abc.def.com
                }
        }
}

This allows me to connect to the backend web servers with ssl enabled on them, and iwth them using SNI. However, I don’t see http3 used? An example log:

2022/04/20 20:22:23.711 ←[35mDEBUG←[0m http.handlers.reverse_proxy upstream roundtrip {“upstream”: “192.168.3.129:443”, “duration”: 0.0012082, “request”: {“remote_addr”: “192.168.3.10:55549”, “proto”: “HTTP/3”, “method”: “GET”, “host”: “killergaming-serverautomation-dev.gssira.com”, “uri”: “/”, “headers”: {“Sec-Fetch-Site”: [“none”], “Sec-Fetch-Dest”: [“document”], “Accept-Encoding”: [“gzip, deflate, br”], “X-Forwarded-Proto”: [“https”], “Cache-Control”: [“max-age=0”], “Upgrade-Insecure-Requests”: [“1”], “Sec-Fetch-Mode”: [“navigate”], “Accept-Language”: [“en-US,en;q=0.9”], “X-Forwarded-For”: [“192.168.3.10”], “User-Agent”: [“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38”], “Accept”: [“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9”], “Sec-Fetch-User”: [“?1”], “If-None-Match”: [“"f9c2494f43ad81:0"”], “If-Modified-Since”: [“Fri, 18 Mar 2022 18:18:33 GMT”]}, “tls”: {“resumed”: false, “version”: 0, “cipher_suite”: 0, “proto”: “”, “proto_mutual”: true, “server_name”: “”}}, “headers”: {“Accept-Ranges”: [“bytes”], “Etag”: [“"f9c2494f43ad81:0"”], “Server”: [“Microsoft-IIS/10.0”], “Alt-Svc”: [“h3=":443"; ma=86400; persist=1”], “Strict-Transport-Security”: [“max-age=0; includeSubDomains”], “Date”: [“Wed, 20 Apr 2022 20:22:23 GMT”]}, “status”: 304}

For the cloudflare stuff, I will park that. I have a better understanding but will pick that up with them.

7

Well, you have right in that log:

So I don’t understand the problem.

8

Looking closer, it seems to be switching between http3 and http2. But I am glad I got everything working with Caddy and it is great!

2 Likes
9

This topic was automatically closed after 30 days. New replies are no longer allowed.