How to use caddy as a reverse proxy under windows 2019 Server

Help
1

I’m completely new to ‘caddy’ and setting up a reverse proxies,

1. The problem I’m having:

No Issue, just checking for suitability of using ‘caddy’ for securing and caching access to LAN from the WAN by acting as a reverse proxy for key web based services on our LAN, we have a mix of Windows/Linux server and devices.

  • Services we like to proxy beyond the basic 80, 443 are mail and monitoring systems.

Would it be possible for some guidance in this matter.

2. Error messages and/or full log output:

No error message

3. Caddy version:

caddy_windows_amd64.exe, 2.7.2

4. How I installed and ran Caddy:

Nort done yet, checking for suitability.

a. System environment:

Windows 2019 Server, native install.

b. Command:

N/A

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

N/A

5. Links to relevant resources:

N/A

2

Yes, Caddy can act as a reverse proxy.

I don’t know what else to say here, your question is very vague, non-specific.

What are you confused about? Did you read the docs? What did you try?

3

My apologies, the question as per subject was just checking before I moved forward, I have read the documentation, as best I can, and can see clearly that it has a reverse proxy function, but it unclear how I would use it. So wanted to confirm first with a simple question.

Since the question I have installed, and done the simple hello world test to check, however I have not managed to get even what seems to be a simple reverse proxy up and running, was about to ask chat gpt. :slight_smile:

As to my specific requirements, I have three servers that have access from the internet that I wise to put behind the reverse proxy.

For now we can call them:

  • server1.domain(.)com with an internal IP 172.16.198.34, https,http,imapa, imap
  • server2.domain(.)com with an internal IP 172.16.198.33, https,http
  • server3.domain(.)com with an internal IP 172.16.198.32, http

Currently all servers have there relevant DNSs setup and are functioning as expected.

Server 1 and 2 have are SSL complaint, server 3 does not have SSL capability so wanting to secure that with SSL via the proxy if possible. Does that help?

4

Caddy is an HTTP/HTTPS server, it cannot proxy IMAP (not in its default distribution anyway, you could proxy arbitrary TCP traffic with GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy but that’s much more advanced and very unlikely to be actually useful for you in this case).

Your config would just look like this:

server1.example.com {
	reverse_proxy 172.16.198.34:80
}

server2.example.com {
	reverse_proxy 172.16.198.33:80
}

server3.example.com {
	reverse_proxy 172.16.198.32:80
}

Caddy will automatically issue TLS certs for each of these domains. No need to proxy over HTTPS since you’re proxying within your local network, so you can simply proxy over HTTP.

5

Thank you, still not really worked as expected so i guess l’m missing something.

Tried with all port 80, but no go at all.

{
    acme_ca https://acme-v02.api.letsencrypt.org/directory
}

vaultc.cfts.co {
	reverse_proxy 172.16.198.19:443
}

mail2.cfts.co {
    reverse_proxy https://172.16.198.44:443
}

download.cfts.co {
	reverse_proxy http://172.16.198.31:8080
}

errors i get in the console are:

2023/08/04 21:54:13.782 e[31mERRORe[0m  tls.obtain      could not get certificate from issuer   {"identifier": "mail2.cfts.co", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 403 urn:ietf:params:acme:error:unauthorized - 41.190.136.10: Invalid response from https://mail2.cfts.co/.well-known/acme-challenge/9lpbnce_BX9b15D4-e8bVR_7Kt-7X8ghYTcNHQdbkFY: 404"}
2023/08/04 21:54:13.783 e[31mERRORe[0m  tls.obtain      will retry      {"error": "[mail2.cfts.co] Obtain: [mail2.cfts.co] solving challenge: mail2.cfts.co: [mail2.cfts.co] authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - 41.190.136.10: Invalid response from https://mail2.cfts.co/.well-known/acme-challenge/9lpbnce_BX9b15D4-e8bVR_7Kt-7X8ghYTcNHQdbkFY: 404 (ca=https://acme-staging-v02.api.letsencrypt.org/directory)", "attempt": 4, "retrying_in": 300, "elapsed": 512.2119037, "max_duration": 2592000}

I’ve tried to look for a typical template for reverse_proxy for ssl sites, what I found seems to be a bit confusing, so guess I’m looking in the wrong place.

Is there a place I can look at working basic templates, so I can play.

6

Your server needs to be publicly reachable on ports 80 and 443, make sure your firewall allows those ports, ports are forwarded, and that DNS for those domains are correctly pointing to your IP address.

If your server can’t be reached, then Caddy can’t set up TLS certs for you automatically.

Also you’ll have a problem with this, if the upstream doesn’t serve a certificate Caddy can trust, then the connection will fail. That’s why I suggested using port 80 to connect over HTTP instead. Traffic is already encrypted from the outside world to your Caddy server, and the rest happens within your network so it’s okay to use HTTP.

7

Ahh I see the issue, incoming public IP is redirected so the proxy never gets the return validation, I need to do some re-jigging with the firewalls.

I use this as my test config, does it look ok?

{
    #acme_ca https://acme-v02.api.letsencrypt.org/directory
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

vaultc.cfts.co {
	reverse_proxy 172.16.198.19:80
}

mail2.cfts.co {
    reverse_proxy 172.16.198.44:80
}

download.cfts.co {
	reverse_proxy http://172.16.198.31:8080
}
8

Yeah, should be fine.

9

I have facused on webmail.cfts.co for the test, works for the certificates,

2023/08/05 12:33:42.725 e[34mINFOe[0m   tls.issuance.acme.acme_client   authorization finalized {"identifier": "webmail.cfts.co", "authz_status": "valid"}
2023/08/05 12:33:42.726 e[34mINFOe[0m   tls.issuance.acme.acme_client   validations succeeded; finalizing order {"order": "https://acme-staging-v02.api.letsencrypt.org/acme/order/113593744/10131758864"}
2023/08/05 12:33:47.259 e[34mINFOe[0m   tls.issuance.acme.acme_client   successfully downloaded available certificate chains    {"count": 2, "first_url": "https://acme-staging-v02.api.letsencrypt.org/acme/cert/fa4c9bcb35abc6ce3aae09a565f59a83fc9f"}
2023/08/05 12:33:47.263 e[34mINFOe[0m   tls.obtain      certificate obtained successfully       {"identifier": "webmail.cfts.co"}
2023/08/05 12:33:47.264 e[34mINFOe[0m   tls.obtain      releasing lock  {"identifier": "webmail.cfts.co"}

But unusable as a reverse proxy it seems, error: webmail.cfts.co redirected you too many times.

Since our system are all secured, ssl’ed, firewalled etc, is it possible to mascaraed/forward the requests? or some how make transparent the redirection.

I was hoping to use ‘caddy’ as a proxy server to streamline my use of public IP’s, maybe using the wrong tool for the wrong job?

UPDATE: Got it working, not sure the logic, I disable the HTTP>HTTPS on the mail server, as I suspect it was coursing a loop, which of course screws over the local (LAN) security, so not exactly a win.
Question: if sufficient public IP’s are available should one use caddy, for anything other than HTTP sites.
Question: is there a way to use this with sites that can only use HTTPS?
Question: can this be used this as a caching proxy.

Here my current/live config, to avoid messing with my other systems. I setup a separate IP and DNS record for the webmail side of the mail server, so it would not interfere with operations while I test.

With my current understanding, ‘Caddy’ is not a useful as I expected it to be, as this disconnects/ affects other operations within our mail system, so on first glance this is only useful for basic http websites/platforms, but still useful.

My current file in total is:

{
    acme_ca https://acme-v02.api.letsencrypt.org/directory
	#acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

webmail.cfts.co {
    reverse_proxy 172.16.198.44:80
}
10

You’ll need to turn off HTTP->HTTPS redirects on your upstream apps.

I don’t understand the question. I think you’re missing some words in there.

Yes, but it adds complexity. You can proxy over HTTPS but then you have to worry about trust – Caddy needs to trust the certificate the upstream servers. Or you can turn off trust checks but then there’s no point to using HTTPS at all because you’re turning off all security anyway, so you might as well use HTTP.

Yes, if you build Caddy with plugins such as GitHub - caddyserver/cache-handler: Distributed HTTP caching module for Caddy

11

Just as an update, I have things working, my security concerns were easily resolved with windows firewall rules, I’ve learnt quite a few new things, thank you, caddy is an amazing tool.

{
    acme_ca https://acme-v02.api.letsencrypt.org/directory
	#acme_ca https://acme-staging-v02.api.letsencrypt.org/directorya
}
(basic-auth) {
  basicauth / {
    *user / hash password*
  }
}

webmail.cfts.co {
  reverse_proxy 172.16.198.44:80
}

download.cfts.co {
  import basic-auth
  reverse_proxy 172.16.198.31:8080
}

redmine.cfts.co {
  reverse_proxy 172.16.198.21:80
}

Question: would really like a way even if complex to bypass caddy internal https engine (if that makes sense) e.g. just pass the request forward, so we can use caddy to access our internal HTTPS only sites.

Takeway: the complexity of caddy is not caddy, its changing existing systems to work with caddy safely, understanding this is really important, as you can go down many deep rabbit holes otherwise, i look forward to learning and using this tool more effetely.

12

Then for that you need a TCP-layer proxy, like I said earlier, e.g. GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy

1 Like
13

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