Proxy issue with TLS forwarding? (Handshake Error) (Solved, not LXD related)


I’m having a bit of an issue with LXD and proxying a TLS server.

When I connect to the TLS server running in a container directly by the container’s address ( it works fine, but when I connect to it via the host machine’s address ( (which should connect to the service running inside the container through the configured proxy device) I get TLS handshake errors…

The proxy device is just set up via
lxc config device add service-tls 9950 proxy listen=tcp: connect=tcp:

It also works fine if I’m connecting over a different port which is serving plaintext and not TLS.

The TLS server is TCP so it shouldn’t be a protocol issue…

Is LXD making any changes to the packets/data sent? is there some other variables I should be using in the proxy device?

Can you show the output of lxc exec <instance> -- ss -tlpn please

As well as the output of lxc config show <instance> --expanded and lxc exec <instance> -- ip a

State              Recv-Q             Send-Q                         Local Address:Port                         Peer Address:Port                                                               
LISTEN             0                  128                                        *:9950                                    *:*                 users:(("tlsvc",pid=26223,fd=5))              
LISTEN             0                  128                                        *:9050                                    *:*                 users:(("tlsvc",pid=26223,fd=6))              
architecture: x86_64
  boot.autostart: "true"
  image.architecture: x86_64  
  image.description: Alpinelinux 3.10 x86_64 (20190818_17:50) alpinelinux-3.10-x86_64-default-20190818_17:50
  image.os: alpinelinux 
  image.release: "3.10" 
  image.serial: "20190818_17:50" 
  image.variant: default
  volatile.base_image: 03e5b32010442300f650384dd71238acc6ac536e371432fdc30c8ae717f5bef3
  volatile.eth0.host_name: vethe212cb10
  volatile.eth0.hwaddr: 00:1e:77:f5:eb:3c 
  volatile.idmap.base: "0" 
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]' '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 687cb4b5-2138-420f-af70-3cd6fc1de410
    connect: tcp:
    listen: tcp:
    type: proxy
    connect: tcp:
    listen: tcp:
    type: proxy
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
    path: /
    pool: Storage
    type: disk
ephemeral: false
- default
stateful: false
description: ""
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
22: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 00:1e:77:f5:eb:3c brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever

So lets check to see how far the traffic is getting.

On the LXD host please can you run:

sudo tcpdump -i any port 9950 -nn

And then make a connection to port 9950 and check you see some activity on the tcpdump command.

Then assuming that works, install tcpdump inside the container and then run inside the container:

sudo tcpdump -i any port 9950 -nn -l

And repeat the test.

Do you see traffic reaching the container?

Also have you checked whether you can connect to the proxied port using something like the telnet command (just to check basic TCP connectivity is working)?


I seem to have fixed the issue, it turned out to not be anything to do with LXD or the proxy device, but the certificates being out of date, regenerating the certificates fixed the problem.

It was allowing me to connect with the invalid certificates locally, but not externally.

Thank you for your time, it helped point me in the right direction.

1 Like