Connecting to Synology NAS with DSM 7

[flyingnobita]

1. Caddy version (caddy version):

v2.4.3

2. How I run Caddy:

a. System environment:

• in a LAN server inside docker
• LAN server is behind pfSense v2.5.1-RELEASE.
• domain DNS is managed in Cloudflare:
  • nas.flyingnobita.com & wg.flyingnobita.com is in Proxy mode “DNS only”
  • other subdomains and domain is in Proxied status
• I have installed a Let’s Encrypt certificate in Synology for domain nas.flyingnobita.com (because I couldn’t get Caddy to automatically get a cert for this subdomain for some reason. Caddy gets certs fine for all other subdomains in the Caddyfile)
• Port forward in pfSense:
  • port 443 / 80 / 5001 to LAN server

b. Command:

Docker Compose file

  caddy:
    container_name: caddy
    image: caddy
    environment:
      - PUID=1000
      - PGID=1000
    ports:
      - 80:80
      - 443:443
      - 2019:2019
      - 5000:5000
      - 5001:5001
    restart: unless-stopped
    volumes:
      - /home/user/caddy/config:/config
      - /home/user/caddy/data:/data
      - /home/user/caddy/Caddyfile:/etc/caddy/Caddyfile
      - /home/user/caddy/public:/usr/share/caddy

c. Service/unit/compose file:

Not sure… maybe N/A for me?

d. My complete Caddyfile or JSON config:

{
  admin 0.0.0.0:2019
  email hello@flyingnobita.com
}
flyingnobita.com {
  templates
}
# Calibre
books.flyingnobita.com {
  reverse_proxy 192.168.1.200:8082
}
# Wireguard
wg.flyingnobita.com {
  reverse_proxy 192.168.1.200:51880
}
# Booksonic
booksonic.flyingnobita.com {
  reverse_proxy 192.168.1.200:4041
}
# Synology
nas.flyingnobita.com {
  reverse_proxy 192.168.1.13:5001
  # reverse_proxy 192.168.1.13:5000 # line commented if the above line isn't
}

3. The problem I’m having:

I’m trying to connect to the NAS web login page with HTTPS but I’m getting the errors below.

4. Error messages and/or full log output:

curl -v https://nas.flyingnobita.com
# shortened for clarity
400 The plain HTTP request was sent to HTTPS port
400 Bad Request
nginx

curl -v https://nas.flyingnobita.com:5001
# or
curl -v http://nas.flyingnobita.com:5000
# shortened for clarity
Sorry, the page you are looking for is not found.
Synology

So it seems that the response from both is coming from Synology which means that it’s at least reaching there somewhat. But obviously, not everything is working.

5. What I already tried:

• inside Synology, disable switching HTTP connections to HTTPS
• inside Cloudflare tried but none worked:
  • switching to different SSL/TLS encryption mode
    • usually is Full(strict)
    • tried all other modes e.g. Off, Flexible, Full
  • switching subdomain from Proxied to DNS Only
• I have been running this setup with Caddy for >1 year and all other subdomains are working (they have different requirements of course)
• What works:
  • port forward 80/443/5001 to NAS internal IP and in browser connect to NAS login page at https://nas.flyingnobita.com
  • port forward 5001 to NAS internal IP and in browser connect to <EXTERNAL_IP:5001>
    • I get a certificate error (expected, as it’s IP and not the domain that the cert is issued for) that I can ignore and login

6. Links to relevant resources:

N/A

[francislavoie]

@flyingnobita

curl -v https://nas.flyingnobita.com
# shortened for clarity
400 The plain HTTP request was sent to HTTPS port
400 Bad Request
nginx

Looks like the request is hitting some nginx server, not Caddy.

Please don’t shorten this, the details are usually relevant.

[flyingnobita]

Sorry. Here’s the screenshot:

[flyingnobita]

And here’s the screenshot for https://nas.flyingnobita.com:5001 and http://nas.flyingnobita.com:5000:

@francislavoie

Looks like the request is hitting some nginx server, not Caddy.

Yes I think the response is from the NAS. i.e. both requests are hitting the NAS.

[francislavoie]

Please post the full output of curl -v. Is there Server: Caddy in it? That would tell us if it’s a response proxied through Caddy or not.

[flyingnobita]

Oh sorry, here it is without my IP.

Yes, Server: Caddy is in the response.

*   Trying <IP_ADDRESS>...

* TCP_NODELAY set

* Connected to nas.flyingnobita.com (<IP_ADDRESS>) port 443 (#0)

* schannel: SSL/TLS connection with nas.flyingnobita.com port 443 (step 1/3)

* schannel: checking server certificate revocation

* schannel: sending initial handshake data: sending 188 bytes...

* schannel: sent initial handshake data: sent 188 bytes

* schannel: SSL/TLS connection with nas.flyingnobita.com port 443 (step 2/3)

* schannel: failed to receive handshake, need more data

* schannel: SSL/TLS connection with nas.flyingnobita.com port 443 (step 2/3)

* schannel: encrypted data got 3465

* schannel: encrypted data buffer: offset 3465 length 4096

* schannel: sending next handshake data: sending 93 bytes...

* schannel: SSL/TLS connection with nas.flyingnobita.com port 443 (step 2/3)

* schannel: encrypted data got 195

* schannel: encrypted data buffer: offset 195 length 4096

* schannel: SSL/TLS handshake complete

* schannel: SSL/TLS connection with nas.flyingnobita.com port 443 (step 3/3)

* schannel: stored credential handle in session cache

> GET / HTTP/1.1

> Host: nas.flyingnobita.com

> User-Agent: curl/7.55.1

> Accept: */*

>

* schannel: client wants to read 102400 bytes

* schannel: encdata_buffer resized 103424

* schannel: encrypted data buffer: offset 0 length 103424

* schannel: encrypted data got 418

* schannel: encrypted data buffer: offset 418 length 103424

* schannel: decrypted data length: 389

* schannel: decrypted data added: 389

* schannel: decrypted data cached: offset 389 length 102400

* schannel: encrypted data buffer: offset 0 length 103424

* schannel: decrypted data buffer: offset 389 length 102400

* schannel: schannel_recv cleanup

* schannel: decrypted data returned 389

* schannel: decrypted data buffer: offset 0 length 102400

< HTTP/1.1 400 Bad Request

< Content-Length: 248

< Content-Type: text/html

< Date: Sat, 03 Jul 2021 04:37:11 GMT

< Server: Caddy

< Server: nginx

<

<html>

<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>

<body>

<center><h1>400 Bad Request</h1></center>

<center>The plain HTTP request was sent to HTTPS port</center>

<hr><center>nginx</center>

</body>

</html>

* Connection #0 to host nas.flyingnobita.com left intact

[francislavoie]

Okay, so Caddy is properly proxying the request. In that case, that means you’re proxying Caddy to the wrong port. Your NAS must have two ports it’s serving content on, an HTTP and an HTTPS port. Use the HTTP port instead.

[flyingnobita]

I tried that and I got the response:

“Sorry, the page you are looking for is not found.”

(I can’t post the image as my account doesn’t allow me to post 2 images in a post)

But then this inspired me to check the DSM settings and I removed the “Customized domain”, it was previously nas.flyingnobita.com.

This worked! Though I wonder why…

Thank you for your help and your speedy reply!

[flyingnobita]

Now that I got it to work, I’m curious and would like to ask more questions, if I may:

1. I thought I configured NAS port 5001 as the HTTPS, and then NAS port 5000 as HTTP. I checked that this seems the case when I connect it locally with the IP address.

Why is it that caddy requires the reverse proxy to use HTTP port?

2. Caddy isn’t able to automatically retrieve and manage the HTTPS certificate for me for this subdomain, any idea on why this is?

[flyingnobita]

Just noticed my original post and some of my replies have been marked as spam.

What makes them spam?

[matt (Matt Holt)]

The system said:

This new user tried to create multiple posts with links to the same domain. All posts from this user that include links should be reviewed.

So I went ahead and restored them.

[francislavoie]

@flyingnobita

Why is it that caddy requires the reverse proxy to use HTTP port?

It doesn’t require it, but it’s simplest, and still secure. Since the connection is happening within your network, if you trust all the machines on your network, then it’s safe. See this topic for an explanation:

Using Caddy as a reverse proxy in a home network

If you want to run a service inside a Local Area Network (LAN) such as your home or office – and especially if you want to be able to access it from outside that network – Caddy can help you accomplish this quite easily. This guide will show you how. It assumes you’ve never done this before, but that you have some technical proficiency and are somewhat knowledgable about your own network. Do this at your own risk. There are several ways to make private services accessible from other n…

If you must use HTTPS to proxy, then use https:// in your upstream address to tell Caddy to try to connect with TLS to the upstream.

The issue with proxying over HTTPS is typically trust. If your upstream doesn’t have a trusted certificate (i.e. issued by a well-known public CA) then Caddy can’t trust it and won’t complete the TLS handshake… unless you throw away all security by using tls_insecure_skip_verify transport option, which is “just as secure” as HTTP, as in, not at all. So might as well use HTTP if you don’t want the headache of managing trust internally.

@flyingnobita

Caddy isn’t able to automatically retrieve and manage the HTTPS certificate for me for this subdomain, any idea on why this is?

Any logs? I see no evidence of that. If you’re able to connect to https://nas.flyingnobita.com with a successful response from Caddy, then you do have a certificate for that domain.

[flyingnobita]

Thank you for your detailed explanation. It really helps me in understanding how Caddy works and increase my networking understanding, and points me in the right direction for further research!

@francislavoie

If you must use HTTPS to proxy, then use https:// in your upstream address to tell Caddy to try to connect with TLS to the upstream.

I was thinking that entering https://nas.flyingnobita.com would be sufficient. Is that what you mean by upstream? And yes I agree that I don’t need https in my own LAN (which is also the case for my other self-hosted services).

@francislavoie

Any logs? I see no evidence of that. If you’re able to connect to https://nas.flyingnobita.com with a successful response from Caddy, then you do have a certificate for that domain.

The logs don’t mention anything about getting a certificate for this subdomain. But this might be because I already manually installed a certificate in the NAS (which I did to troubleshoot the connection problem that is now solved). I guess a good test would be to remove that certificate and see what Caddy does. Though the NAS is in heavy use now since it is working so I can’t risk it not working, I guess I’ll have to come back to this test.

[francislavoie]

@flyingnobita

Thank you for your detailed explanation. It really helps me in understanding how Caddy works and increase my networking understanding, and points me in the right direction for further research!

@flyingnobita

I was thinking that entering https://nas.flyingnobita.com would be sufficient. Is that what you mean by upstream? And yes I agree that I don’t need https in my own LAN (which is also the case for my other self-hosted services).

By “upstream” I’m talking about the first argument to reverse_proxy. The “upstream” is the thing that Caddy sends the request to, when proxying.

So instead of reverse_proxy 192.168.1.13:5001, you might do reverse_proxy https://192.168.1.13:5001. But like I said, this likely wouldn’t work as-is, you’d need to make sure the correct Host header is sent (since the upstream server probably picks the certificate to use based on the Host header or SNI) and then you’d need to deal with the issue of trust, like I wrote earlier.

@flyingnobita

The logs don’t mention anything about getting a certificate for this subdomain.

Caddy probably issued the cert for nas.flyingnobita.com in an earlier run. It won’t log issuance if issuance doesn’t happen. And renewal only happens after 2/3 of the lifetime of the cert, i.e. 90 day lifetime, so after 60 days a renewal is attempted. You could look in Caddy’s storage location to find the certificate/key, i.e. in /home/user/caddy/data, your docker volume for /data.

@flyingnobita

I guess a good test would be to remove that certificate and see what Caddy does.

Yep, you could do that. Don’t delete it too often though cause you could hit Let’s Encrypt rate limits (but it’s pretty hard to hit the rate limits, they’re pretty generous Rate Limits - Let's Encrypt and as an aside ZeroSSL has no rate limits).

[flyingnobita]

@francislavoie

So instead of reverse_proxy 192.168.1.13:5001, you might do reverse_proxy https://192.168.1.13:5001. But like I said, this likely wouldn’t work as-is, you’d need to make sure the correct Host header is sent (since the upstream server probably picks the certificate to use based on the Host header or SNI) and then you’d need to deal with the issue of trust, like I wrote earlier.

I didn’t know this was possible. Thanks for pointing this out. And yes it didn’t work for me as you said.
I did find a setting to customize the server header. I’ll need to investigate more on this to (probably w/ the Synology guys) to see how best to do this.

@francislavoie

Yep, you could do that. Don’t delete it too often though cause you could hit Let’s Encrypt rate limits (but it’s pretty hard to hit the rate limits, they’re pretty generous Rate Limits - Let’s Encrypt and as an aside ZeroSSL has no rate limits).

Yes indeed, thanks for the tip!