Using Teleport behind Caddy as a reverse proxy

[webvictim]

Edit (December 2024): Teleport has supported tunnelling its TLS multiplexing over websockets since the release of Teleport 15.1, so this guide has been updated with that in mind to remove the requirement to use separate ports.

---

A question that comes up often is how to deploy Teleport with a reverse proxy (like Caddy) in front of it, so that people deploying in homelabs can still expose other public services other than Teleport on the same home IP.

Here's an example of how I did this with Caddy.

Notes

• example.com is my domain
• Caddy is listening externally on port 443 (see "Port Forwarding" below)
• teleport.example.com is the subdomain that Caddy will redirect to the Raspberry Pi I have running Teleport (artemis), where Teleport is listening on port 3080.
• The wildcard *.teleport.example.com is also configured, so I can use applications on subdomains of Teleport using Teleport application access.
• I have DNS A records configured for teleport.example.com and *.teleport.example.com which point to the public IP address of my router.
• Caddy automatically gets and serves TLS certificates from Let's Encrypt for teleport.example.com and *.teleport.example.com
  • My Teleport cluster also has certs from certbot configured under https_keypairs, but this is not a hard requirement when using a reverse proxy.
    • You can remove the tls_insecure_skip_verify from your Caddy config and replace it with tls_server_name teleport.example.com if you also have this set up.

External port forwarding

• 443/tcp is forwarded to port 443 on the Caddy host

Caddy configuration

Caddy's configuration goes into a file called Caddyfile. It also has a Caddyfile.d directory where you can drop configurations for individual sites, rather than using a monolithic config file.

/etc/caddy/Caddyfile.d/teleport.caddyfile:

teleport.example.com, *.teleport.example.com {
    tls {
        dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN}
    }
    reverse_proxy https://artemis:3080 {
                transport http {
                        tls
                        tls_insecure_skip_verify
                }
        }
}

The dns cloudflare line here means that Caddy will perform DNS-01 challenges using Cloudflare, with a token provided via the CLOUDFLARE_AUTH_TOKEN environment variable. If you don't use Cloudflare you can remove the bracketed section and just leave tls by itself to do challenges using the default mechanism. Wildcard certs will require the use of a DNS-01 challenge, however.

Teleport configuration

Teleport is installed straight onto a Raspberry Pi and uses the config file below. You can use the same host as Caddy if you like - just change the mention of artemis in the caddy config to localhost instead.

/etc/teleport.yaml:

version: v3
teleport:
  log:
    output: stderr
    severity: DEBUG
  data_dir: /var/lib/teleport
auth_service:
  enabled: yes
  cluster_name: teleport.example.com
  authentication:
    type: github
    second_factor: webauthn
    webauthn:
      rp_id: teleport.example.com
ssh_service:
  enabled: yes
  labels:
    type: node
  commands:
  - name: hostname
    command: ['/bin/hostname']
    period: 1h0m0s
  - name: teleport_version
    command: ['/usr/local/bin/teleport', 'version']
    period: 1h0m0s
  - name: arch
    command: ['/bin/uname', '-m']
    period: 1h0m0s
  - name: os
    command: ['/bin/uname', '-s']
    period: 1h0m0s
proxy_service:
  enabled: yes
  web_listen_addr: 0.0.0.0:3080
  # the public address is the public hostname/port that can be used to connect to Teleport from the outside
  # Caddy listens on port 443 and redirects to 3080, where Teleport's web UI is served
  public_addr: teleport.example.com:443
  # (optional) Paths to certs from certbot
  https_keypairs: {}

Config for agents joining remotely

version: v3
teleport:
  proxy_server: teleport.example.com:443

[dyay108]

thanks for this. got my setup going.

[cooling75]

Thanks for this! I'm using traefik (still with http challenge) and was struggling the whole day.

[estradeb]

Some more documentation to help anyone trying this. I had to do this with OVH dns provider

• Ovh module

• build and install the new binary
  I placed my binary in /usr/bin/caddy.custom and pointed the systemd file to point to it (/usr/lib/systemd/system/caddy.service)

Make sure you are using the build with the plugin installed
caddy list-modules | egrep ovh

/usr/lib/systemd/system/caddy.service :

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy.custom run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy.custom reload --config /etc/caddy/Caddyfile --force
TimeoutStopSec=5s
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
Environment='OVH_APPLICATION_KEY=xaxaxaxa'
Environment='OVH_APPLICATION_SECRET=xaxaxaxaxaxaxaxa'
Environment='OVH_CONSUMER_KEY=xaxaxaxaxaxaxaxa'
Environment='OVH_ENDPOINT=ovh-eu'

OVH is also making it pretty annoying to manage application tokens and give it the correct permissions.
This guy pointed out the solution

curl -XPOST -H "X-Ovh-Application: <Application Key>" -H "Content-type: application/json" https://eu.api.ovh.com/1.0/auth/credential -d '{"accessRules":[{"method":"POST","path":"/domain/zone/<Nom De Domaine>/record"},{"method":"POST","path":"/domain/zone/<Nom De Domaine>/refresh"},{"method":"DELETE","path":"/domain/zone/<Nom De Domaine>/record/*"}],"redirection": "https://www.foo.com"}'