"incus remote add" through NAT?

I am unable to connect to an incus server that’s behind a NAT using standard NAT port forwarding.

Here’s the setup

GLOBAL_IP <–firewall with NAT port forwarding 8443 → INCUS_IP (private)

I have no problems with “incus remote add” for a remote incus server if the server sees the remote connection coming from the local network (e.g. accessed via VPN or a local net).

However when the remote client has a different IP subnet from the server it gets denied.

On the Incus server:

$ incus config show
config:
  core.https_address: '[::]:8443'

$ ss -tna | egrep -e "(8443|State)"
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096               *:8443            *:*           

$incus version
Client version: 6.0.1
Server version: 6.0.1

Here’s what I’ve tried on the client:

incus remote add NAME GLOBAL_IP

incus remote add NAME GLOBAL_IP --token XXXX

incus remote add NAME GLOBAL_IP --token=XXXX

where XXX is the token given at the server with incus config trust add REMOTE

But I always get an instantaneous reply of

DEBUG  [2024-07-03T00:01:26-05:00] Connecting to a remote Incus over HTTPS       url="https://GLOBAL_IP:8443"
DEBUG  [2024-07-03T00:01:26-05:00] Sending request to Incus  etag= method=GET url="https://GLOBAL_IP:8443/1.0"
Error: Get "https://GLOBAL_IP:8443": Unable to connect to: GLOBAL_IP:8443 ([dial tcp GLOBAL_IP:8443: connect: connection refused])

I’ve checked iptables and nft and they are totally open.

Again, I have no problems if the client is on the same subnet as the server.

The documentation states

When generating the token on the server, Incus includes a list of IP addresses that the client can use to access the server. However, if the server is behind NAT, these addresses might be local addresses that the client cannot connect to. In this case, you must specify the external address manually.

but I don’t see where to do that? If I run incus config trust list -c ntcfdierp I don’t see IP in the list of restrictions.

Any suggestions?

The error makes it sound like an issue with network connectivity, whether it’s the NAT configuration or some other firewalling rather than an issue with Incus itself.

For those kind of cases, I tend to use nc -v PUBLIC-IP 8443 to test things in isolation, basically just testing that the network connection itself makes it through before going back to the Incus CLI.

Thanks,

I assumed that because it was instantly being rejected instead of timing out that it was setup correctly from the NAT perspective. I ended up running tcpdump to watch the raw traffic and found the NAT redirecting to the right server but wrong port.