[v2] reverse_proxy with self signed node fails on IP?

[svenakela (Sven)]

So I am migrating a bunch of proxied servers to Caddy v2 but ran out of luck. The luck ends when I try to use TLS between the machines, and I need it in this network.

1. Caddy version (caddy version):

2.0.0

2. How I run Caddy:

Two Docker containers (official image) on the same machine
The LAN name for the server is dmz-02 and is served on 192.168.10.105
The two Docker containers are NOT connected to the same Docker network, they can only communicate via the host IP and exposed ports.
One container is a reverse proxy.
The other one is a container serving a dev test server (IP 172.25.0.8).

a. System environment:

Docker in Linux

b. My complete Caddyfile or JSON config:

Working Proxy Config:

dmz-02, dmz-02.lan {
    tls internal
    reverse_proxy {
        to http://192.168.2.3:2080
    }
}

Working Node Config:

http://dmz-02 {
    respond "Local Test"
}

NOT WORKING Reverse Proxy Config

dmz-02, dmz-02.lan {
    tls internal
    reverse_proxy {
        to https://192.168.2.3:2443
            transport http {
                tls
                tls_insecure_skip_verify
            }
    }
}

NOT WORKING Working Node Config:

dmz-02 {
    tls internal
    respond "Local Test"
}

3. The problem I’m having:

When the two working config files above is in use, the proxying works. When I enable TLS (the two non working configs), it seems that the test container tries to serve a web page under the local IP instead of serving the domain name that is sent from the proxy?
Instead of getting “Local Test” as a response, I get 502 Bad Gateway

4. Error messages and/or full log output:

So this is what happens when the NON WORKING config is in use.

http: TLS handshake error from 172.25.0.1:34030: no certificate available for ‘172.25.0.8’

5. What I already tried:

Everything I found the last seven hours…

6. Links to relevant resources:

I thought my issue was related to this question, but the example is not served by Caddy and when I do it Caddy only it seems to break.

502 error when proxy to caddy https upstream

os: Ubuntu16.04 Caddy:0.11 nginx:1.14.1 Host A: 172.18.0.1, caddy1(reverse proxy, as front) Host B: 172.18.0.2, caddy2(backend with https, as backend) Host C: 172.18.0.3, nginx(backend with https and without no default_server option, as backend) caddy1: www.domain1.com { proxy / https://172.18.0.2 { insecure_skip_verify transparent } header / -Server tls { dns cloudflare } } www.domain2.com { proxy / https://172.18.0.3 { insecure_skip_verify transparen…

Please help, pretty please.

[svenakela (Sven)]

Another detail, if I add the IP-adress as a serving name in the config, it works. But I expect a domain name getting to the backend node.

[Whitestrake (Matthew Fay)]

I don’t think Caddy uses SNI for upstreams, so the upstream server is inferring the server name as its IP address and rejecting it because the IP address doesn’t match a site it’s configured to serve HTTPS for.

This has nothing to do with the Host header, mind, which will still make its way to your backend server.

Try setting the default_sni to your dmz-02 so that the upstream server will assume the downstream server wants that site.

• default_sni sets a default TLS ServerName for when clients do not use SNI in their ClientHello.

—Global options (Caddyfile) — Caddy Documentation

[francislavoie]

Actually the correct option to use would be tls_server_name on the client (i.e. in the reverse_proxy transport) but that’s not yet available in v2.0, will be available in v2.1:

reverseproxy: Add tls_server_name http transport option to Caddyfile

default_sni on the upstream server should probably work as a workaround for now though.

[Whitestrake (Matthew Fay)]

Excellent! That’ll solve things quite nicely when 2.1 rolls around.

[svenakela (Sven)]

Ok, thanks guys. Looks like 2.1 will be a better choice for proxying.