Anyone using Caddy on Docker on a Synology NAS (as Reverse Proxy only)?

Prodeje · June 24, 2017, 7:12pm

SHoot I missed this! I attempted to start without the caddyfile change! it failed to start. I will try correcting the caddyfile and try again.

SO basically change
proxy /sonarr 127.0.0.1:8989 {
transparent
}
to
proxy /sonarr sonarr:8989 {
transparent
}

for each?

Thoughts on how to do that DiskStation?
We have that redir coded…
proxy / 127.0.0.1:5000 {
transparent

Prodeje · June 24, 2017, 7:35pm

I removed the auto to 2015 port mapping as a trouble shooting step. No dice as in wont create the container. NO good error message or log.

Next I removed the 3 links for the corresponding containers sonarr,nzbget, and radarr.

This time it started. Unfortunately I got this…
Looks like I need to use a new email address too as I am rate limited…

failed to get certificate: acme: Error 429 - urn:acme:error:rateLimited - Error creating new authz :: Too many invalid authorizations recently.

Is there another way without the aliases? what do i change these too if the 127 nor these aliases can work?

proxy /sonarr sonarr:8989 {
transparent
}

Whitestrake · June 24, 2017, 7:36pm

The Caddy container can see the host by its IP address on the local network now, so use the IP of your NAS instead of 127.0.0.1.

Whitestrake · June 24, 2017, 7:40pm

Bummer. LetsEncrypt locked you out for making too many failed certificate requests. You will have to wait a week for the rate limit to clear.

The aliases aren’t stopping Caddy from working. Caddy will start up with a proxy to literally anywhere, it doesn’t have to be valid - the errors will come later when you try to connect via that proxy (it would give you error 502 if the upstream isn’t reachable). If those containers are linked correctly, though, they’ll be fine.

The problem is probably something wrong with the port forwarding. :80 and :443 on the router MUST reach :8080 and :8443 on the NAS, and Caddy MUST have the ports :8080 and :8443 on the NAS mapped to :80 and :443 in the container. If there’s anything not lined up right, the ACME challenge will fail, Caddy will exit, and as you specified auto-restart, it will repeat this again and again (and LetsEncrypt has rate limited you as a result).

Prodeje · June 24, 2017, 7:47pm

Can I use a different email and/or DDNS to not wait a week?

I don’t understand why, but it is the aliases that keep the container from even starting. As soon as I removed those 3 it readily started. With the 3 in there, it just says “Create container abiosoft-caddy1 failed.” No other info

Whitestrake · June 24, 2017, 8:01pm

If you can change your DDNS, yep. You can also use the LetsEncrypt staging endpoint. In fact I’d highly recommend that. Or turn auto restart off until you’ve got all the config nailed. Or all of the above, really.

Can’t be… Rewrite the proxy directive out again, something might be mistyped.

I just started up an instance of Caddy 0.10.3 on my PC with a proxy / some-imaginary-backend:80 (literally) and it runs fine. Needless to say there is no some-imaginary-backend available on my network. Conks out when I try to access localhost:2015, though (error 502).

Worst case scenario, remove the links entirely, change the upstream in all your proxies to your NAS IP on the LAN, and try again.

Prodeje · June 24, 2017, 11:04pm

I did have a second DDNS setup that I was wanting to move to. I used that and a different email address.

I redid everything and made a new container, including the 3 aliases. It will not create the container. It bothers me as I dont understand a reason.

I remove those 3 aliases. Then it creates the container and starts up perfectly. Everything is working from my cellphone not on my wifi. Sonarr, RAdarr, and Synology are perfect. I am indeed using my NAS IP address in my caddy file since i cant get it to take the aliases.

WHat else can i try in regards to getting that to work with aliases? very weird.

nzbget isn’t working. I do have nzbget requiring its stock userID and pw. First I get prompted for the proxy pw via pop-up. Then I get another pop-up that I presume is the nzbget web password. Does that not play nice together and I should remove the nzbget web server app password?

Whitestrake · June 24, 2017, 11:07pm

NZBGet auth is basic too, I think. Turn it off. Basic auth uses the Authorization header, which obviously can’t hold both Caddy’s required credential and NZBGet’s as well (unless they’re identical).

Prodeje · June 24, 2017, 11:17pm

Yep that was it. Looking in the logs, it was indeed passing the basic auth creds to nzbget! I guess I dont need it any more anyway!

Prodeje · June 26, 2017, 2:31pm

So far so good still! So happy! Ill whip up a guide for the community and see if any other tweaks needed.

Are you familiar with nzb360? Technically i don’t need it, but curious if you know how to get it working with caddy.

It allows for local and remote setup. basically using a comma.
My local setup works fine, but I cannot get remote to work.
The key fields are:
IP/Host Address (notes to input HTTP auth as user:pass@host): IP_OF_NAS,myuser:mypass@CustomDDNSName.DDNSProvider.com

Server Port (If you are using a sub dir, enter it after the port): 8989/sonarr,80/sonarr

I assume its probably an issue with caddy starting at 80 and then wanting to go to 443?

I found one older thread: nzb360

Prodeje · June 26, 2017, 3:03pm

I also took a stab at converting to the full CNAME setup and merging into one Caddyfile without common.conf.

https://zerobin.net/?fb716416c8de9ebd#P2Ymysw6yAXrqPtn+QPJR+8zT3rcJkIEyKxmgRqbdHA=

Thoughts? definitely less pleasing to look at! What are your thoughts on condensing? Maybe go back to common.conf?

I was unsure how to handle the redirs for sure, but took a guess

Whitestrake · June 26, 2017, 3:58pm

Tried it a while back. It never played nice for me, not through Caddy remotely. But I’ve found the webapps render just fine on mobile regardless.

A pretty good stab I’d say, but you’re right about it looking a little less pleasing without the common.conf…

To be honest, here’s my entire Caddyfile:

sub.example.com {
	tls sub@example.com
	errors stdout
	log stdout
	gzip
	
	header / {
		Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
		X-XSS-Protection "1; mode=block"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "DENY"
	}

	basicauth [user] [pass] {
		/radarr
		/hydra
		/nzbget
		/sonarr
	}

	proxy /radarr 192.168.1.123:7878
	proxy /hydra 192.168.1.123:5075
	proxy /nzbget 192.168.1.123:6789
	proxy /sonarr 192.168.1.123:8989
	proxy /ombi 192.168.1.123:3579
	proxy / 192.168.1.123:19999
}

sub.example.com/couchpotato {
	redir /radarr/
}

Prodeje · June 26, 2017, 6:04pm

Awwww yisssssss much nicer and clean.

Will this will work fully using the CNAME approach and I should then remove the URL base pieces from each app where applicable?

I also wanted to clarify how to handle the synology 5000 port route.

I also wanted to clarify how to handle the circumstance when just the root / is used. In my case I want / to go to sonarr.

Do I need a basicauth for when just / is accessed and routes to sonarr? Or maybe not because it then routes to sonarr which needs the auth?

updated Caddyfile: (how do you get the tabs in the quotes to work???)

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
/synology
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878
proxy /synology YOUR_NAS_LOCALIP:5000
proxy / YOUR_NAS_LOCALIP:8989 # Root will take to Sonarr
}

nzbget.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /nzbget/
}

sonarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /sonarr/
}

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /radarr/
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /synology/
}

matt · June 26, 2017, 6:33pm

Use three backticks to make code blocks (Markdown)

Prodeje · June 26, 2017, 6:40pm

Done! I had to google backticks!

Whitestrake · June 26, 2017, 11:17pm

All apps proxied into a subfolder must have their URL base set.

In your updated Caddyfile, it looks like you’ve proxied both / and /sonarr to Sonarr. I would instead redir / /sonarr. To answer your next question as well, a basicauth on /sonarr will then handle that when the client arrives.

Those redirs look good. One note - does Synology have a URL base option? I thought you were going to proxy synology.example.com to your NAS, not example.com/synology, but I maybe wrong.

Prodeje · June 27, 2017, 12:28am

Oh yes, the synology does not have a base URL option… i just need to get to YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X:5000

so i need to add a redir higher up and then a full site below? do I also need to add another basicauth for the synology piece?

do we not need the transparent preset anywhere?

here’s the revised slim version:

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878
proxy /synology YOUR_NAS_LOCALIP:5000
redir / /sonarr # Root will take to Sonarr
redir /synology synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X
}

nzbget.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /nzbget/
}

sonarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /sonarr/
}

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /radarr/
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
proxy / YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X:5000
}

Whitestrake · June 27, 2017, 12:37am

Rip out the proxy /synology, it’s useless with redir /synology (redir beats proxy).

Change redir /synology synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X to redir /synology https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X , will avoid a double redirect (from Caddy HTTP->S upgrade).

Under the label block for synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X, yes, add a blanket basicauth / here. Also change the upstream to YOUR_NAS_LOCALIP, currently it proxies to itself but on port 5000 (I hope this is not open externally).

Not terribly, no. Sonarr, Radarr, and NZBGet don’t particularly care who the real client is and function just fine without knowing.

Looking good otherwise!

Edit: Also minor heads up - in my header block from my “slim” Caddyfile I didn’t bother with -Server. I don’t know if you caught that removal but just in case you particularly want to have that, you should re-add it.

Prodeje · June 27, 2017, 12:04pm

Thank you so much!

I do not have port forwarding to 5000 on my router, so it should not be exposed externally, should I test this somehow?

One final check please before i create this guide!

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878
redir / /sonarr # Root will take to Sonarr
redir /synology https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X
}

nzbget.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /nzbget/
}

sonarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /sonarr/
}

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /radarr/
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
basicauth / YOUR_USERID YOUR_PASSWORD
proxy / YOUR_NAS_LOCALIP:5000
}

Whitestrake · June 27, 2017, 3:42pm

I’ll bet it’s not open (if it was, it’d probably have been because you opened it, and you’d know). But you could grab nmap and run nmap -p 5000 YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X and see if it comes back with a result, if you wanted to double check.

Actually, looking over, a few things…

1.

redir /synology https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X

Instead of this structure, in my Caddyfile above you’ll see I went with

example.com/subdomain {
  redir / https://subdomain.example.com
}

The reason being that the former won’t catch example.com/subdomain/ (only example.com/subdomain, no trailing slash), whereas the latter catches both (and anything else, e.g. example.com/subdomain/foo/bar). This one’s up to you if you care about that.

2.

I know I told you earlier to redir / /sonarr, but I’ve got a feeling that’s going to win over everything else and cause a redirect loop, because the form redir / is a catch-all and

So you might need to use this structure instead, so only requests for EXACTLY / get redirected:

redir 301 {
  if {path} is /
  to /sonarr
}

3.

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  redir /radarr/
}

This structure is a redirect loop. /radarr/ is relative so it never breaks out of the subdomain, redirecting forever. You want this instead:

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  redir YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X/radarr/
}

Or just ditch those three redir blocks entirely and don’t hand out service.example.com style subdomains (except for synology).