The way migration works out of the box is that your CLI tool will tell the destination to connect to the source. Your firewall rule looks like it may be backward for that flow and so not allow the connection.
You can reverse the direction with --mode=push or even make everything go through the CLI (which is almost always guaranteed to work, but can be slower) with --mode=relay.
What about copying containers over the internet and encryption? I’m in the process of moving servers. After the move, there is no longer an internal network for containers. Is a copy or move encrypted?
Yep, all LXD communication whether it’s between your CLI and a server or server to server is done over LXD’s TLS API (port 8443).
During the migration, the client ask the source server to create a websocket migration operation, this comes with 3 different sockets each with their own secret. The client then posts to the target server and gives it, the URL of the source server, the TLS certificate to expect from the source server (preventing MITM attacks) and the secrets to use to access the source instance.
That target server can then connect to the source over HTTPS, can validate the certificate and then using those secrets, connect to the migration API for that specific instance. The target server never has access to anything other than the instance that’s being transferred and all communications between the two servers happen over that HTTPS connection.