TURN and Trickle ICE not connecting?

[wallaby-gopher]

Hello,
I wasn’t getting anywhere with nextcloud’s built-in talk (see thread here), so I thought I’d try spinning up eturnal.
I get some results with turn:[machine’s public ip]:port via (Trickle ICE) on firefox librewolf, but I now think the last result means it didn't actually connect. I got the machine's IP with curl -s http://tnx.nl/ip

especially with

$ docker logs eturnal | egrep 'request|authentication|allocation'
egrep: warning: egrep is obsolescent; using grep -E
Cannot query stun.conversations.im:3478: network is unreachable
Cannot query stun.conversations.im:3478: network is unreachable
Cannot query stun.conversations.im:3478: network is unreachable
Cannot query stun.conversations.im:3478: network is unreachable
Cannot query stun.conversations.im:3478: network is unreachable
Cannot query stun.conversations.im:3478: network is unreachable

I also tried with a user/pass by running docker exec eturnal eturnalctl credentials and inputting those into trickle, no dice.

I get a little message on chrome

docker-compose:

networks:
  bridge_network:
    name: bridge_network
    external: true
  backend_network:
    name: backend_network
    external: true
  nextcloud-aio:
    name: nextcloud-aio
    external: true

services:
  #for nextcloud talk to work outside of network
  eturnal:
    image: ghcr.io/processone/eturnal:latest
    networks:
      - backend_network
      - nextcloud-aio
    hostname: eturnal
    container_name: eturnal
    restart: unless-stopped
    user: 9000:9000

    ### security options
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    ### Note: if eturnal binds to privileged ports (<1024) directly, the option "security_opt" below must be commented out.
    security_opt:
      - no-new-privileges:true

    ### networking options
    ports:
      - 3480:3478     # STUN/TURN non-TLS | 3478 already in use by nextcloud backend?
      - 3480:3478/udp # STUN/TURN non-TLS | 3478 already in use by nextcloud backend?
      # - 5349:5349   # STUN/TURN TLS
      # - 49152-65535:49152-65535/udp # TURN relay range
    # network_mode: "host"

    ### Environment variables - information on https://eturnal.net/doc/#Environment_Variables
    # environment:
    #   - ETURNAL_RELAY_IPV4_ADDR="203.0.113.4" ##might need and change to tailscale ip?
    #   - ETURNAL_RELAY_IPV6_ADDR="2001:db8::4"
    #   - STUN_SERVICE="false"
    # env_file:
    #   - eturnal.env

    ### Volume mounts - Note: directories/files must be (at least) readable by the eturnal user (9000:9000)
    volumes:
      - /media/server/server/turn/eturnal.yml:/etc/eturnal.yml:ro # for custom config file
    #   - /path/to/tls-files:/opt/eturnal/tls      # for custom tls files

config:

#https://nextcloud-talk.readthedocs.io/en/latest/eturnal/
eturnal:
  ## Shared secret for deriving temporary TURN credentials (default: $RANDOM):
  secret: "[snip]"     # Shared secret

  ## The server's public IPv4 address (default: autodetected):
  #relay_ipv4_addr: "203.0.113.4"
  ## The server's public IPv6 address (optional):
  #relay_ipv6_addr: "2001:db8::4"

  listen:
    -
      ip: "::"
      port: 3480
      transport: udp
    -
      ip: "::"
      port: 3480
      transport: tcp

Is port forwarding necessary?

Any input is appreciated.

[sando38]

Cannot query stun.conversations.im:3478: network is unreachable

Hm.. what happens here in the container image is, that it tries to call a STUN server, but that error indicates somewhat that the call does not go out. So, in your place I would check first if you generally can have incoming and outgoing udp traffic. Probably, if this is the reason and you solve it, the built-in turn in Nextcloud AIO will work also.

[wallaby-gopher]

Cannot query stun.conversations.im:3478: network is unreachable

Hm.. what happens here in the container image is, that it tries to call a STUN server, but that error indicates somewhat that the call does not go out. So, in your place I would check first if you generally can have incoming and outgoing udp traffic. Probably, if this is the reason and you solve it, the built-in turn in Nextcloud AIO will work also.

Okay, derp, accidentally hit in 3080 instead of 3480, I get more results but still a "not reachable?"

I am still curious about UDP, and can list a few with netstat?

$ docker exec -it eturnal netstat -a -p UDP
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 localhost:3470          0.0.0.0:*               LISTEN      7/eturnal
tcp        0      0 localhost:46471         0.0.0.0:*               LISTEN      -
tcp        0      0 localhost:48698         localhost:3470          TIME_WAIT   -
tcp        0      0 localhost:48704         localhost:3470          TIME_WAIT   -
tcp        0      0 localhost:48706         localhost:3470          TIME_WAIT   -
tcp        0      0 :::3480                 :::*                    LISTEN      7/eturnal
udp        0      0 localhost:55805         0.0.0.0:*                           -
udp        0      0 :::3480                 :::*                                7/eturnal
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  3      [ ]         STREAM     CONNECTED     111096 7/eturnal           
unix  3      [ ]         STREAM     CONNECTED     111097 258/erl_child_setup 

So then I tried running a netcat on the hostmachine

$ nc -z -v -u 0.0.0.0 3478 
Connection to 0.0.0.0 3478 port [udp/stun] succeeded!

oops, that's the container side port, why'd that work?

$ nc -z -v -u 0.0.0.0 3480 
Connection to 0.0.0.0 3480 port [udp/plethora] succeeded!

not sure what to make of plethora either, and from another network+computer it works with both again

$ nc -z -v -u [pub ip] 3480 
Connection to [pub ip] 3480 port [udp/plethora] succeeded!
$ nc -z -v -u [pub ip] 3478 
Connection to [pub ip] 3478 port [udp/stun] succeeded!

[sando38]

what I am noticing about your compose is in ports: 3480:3478 . since you map to the container ports which you changed to 3480 you should reflect this in the ports section as well: 3480:3480.

[wallaby-gopher]

what I am noticing about your compose is in ports: 3480:3478 . since you map to the container ports which you changed to 3480 you should reflect this in the ports section as well: 3480:3480.

I changed that section to:

      - 3480:3480     # STUN/TURN non-TLS | 3478 already in use by nextcloud backend?
      - 3480:3480/udp

and I turned off nextcloud, yup, only response is from 3480. Pleathora maybe refers to STUN and TURN?
I still couldn't get trickle or nextcloud to work with the public IP, but I did finally try my tailscale address

Hey, if it works, it works (even if it is probably very convoluted and wrapping back and forth).
I may try to recover the talk embedded TURN and just change it's address to the tailscale one rather than run another eturnal also.

Thanks for your help!

[sando38]

Cool, thx for the feedback.

[wallaby-gopher]

I seem to have spoken too soon.
The tailscale machine I used above is the host machine's native metal, I falsely assumed I could make another tailscale node to attach in docker for security's sake.

  tailtalk:
    container_name: tailtalk
    #links:
     # - eturnal
    #hostname: tailtalk #not in host mode
    cap_add:
      - NET_ADMIN
      - NET_RAW
      #- sys_module #serve didn't work from https://www.elliotblackburn.com/how-to-use-tailscale-serve-with-docker-compose-for-secure-private-self-hosting/
    volumes:
      - tailtalk-data:/var/lib
      - tailtalk-state:/state
      - /dev/net/tun:/dev/net/tun
     # - /media/server/server/turn/config:/config #serve didn't work
     # - /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket:ro #from here https://github.com/tailscale/tailscale/issues/9559
    network_mode: host
    #extra_hosts:
      #- "host.docker.internal:host-gateway" #from https://stackoverflow.com/questions/56582446/how-to-use-host-network-for-docker-compose
    #networks:
     # - backend_network
      #- nextcloud-aio
    #adding from here https://forum.tailscale.com/t/no-internet-when-using-linux-docker-as-exit-node/3155/2
    # privileged: true #did not help with TURN
    restart: always
    environment:
      - TS_HOSTNAME=talk
      #not needed for exit node?
      #only needed for subnet?
      #- TS_ROUTES=192.168.1.0/24
      #only needed for subnet
      #- TS_EXTRA_ARGS=--accept-routes #=true
      #- TS_EXTRA_ARGS=--advertise-exit-node
      #want logs
      #- TS_NO_LOGS_NO_SUPPORT=true
      - TS_STATE_DIR=/state
    image: tailscale/tailscale:latest
    #command: tailscale serve 3480 #attempt to explictly share port?

I tried all sorts of weird things, but only host mode will allow it to even connect inside nextcloud. NO amount of sharing in tailscale, even completely unrestricted will allow calls to actually connect off network.
the log has some connection refused's despite 100.66.8.78:3480 being WIDE open.

2025/07/17 19:59:12 CreateEndpoint error for 100.91.72.49:36195 -> 100.66.8.78:3480: connection was refused

2025/07/17 19:59:12 CreateEndpoint error for 100.91.72.49:42069 -> 100.66.8.78:3480: connection was refused

2025/07/17 19:59:12 CreateEndpoint error for 100.91.72.49:36773 -> 100.66.8.78:3480: connection was refused

2025/07/17 19:59:17 CreateEndpoint error for 100.109.65.127:57859 -> 100.66.8.78:3480: connection was refused

So with that in mind I thought I'd test arch.
First I tried sharing arch (synonymous with 100.91.72.49) with a boilerplate acl control:

{
			"action": "accept",
			"src":    ["*"],
			"dst":    ["100.91.72.49:3480"],
		},

It will not connect off network.
Fine, let's loosen the security, 100.91.72.49:* but that will not work either, like it would need to connect to another ip, but it's on the machine so it SHOULD work. (every web container can be opened with arch:ip)
with me alone having access to : only then will it connect calls off network.
Just as an example, why doesn't tailtalk work as :, that would be synonymous total access?
Any idea what I'm missing here?

[sando38]

I do not know what tailscale is, I may be too tired to understand, but your exact issue is, that a docker container "nextcloud" cannot connect to a docker container "eturnal"? One of them running in host network, the other not? Are both running on the same host? do they share the same docker network?

[wallaby-gopher]

I do not know what tailscale is

Tailscale just functions as a wireguard VPN that usually allows me to avoid port forwarding. For example, as long as an external device has tailscale, I've shared it, and my ACL's allow -- it can connect as if it was on a local network. I reverse proxy with caddy, so family member can connect to things like nextcloud as if it was a regular website via my defined "nextcloud.wallaby-gopher.ts.net", but it's unreachable from the Wild West Web.

I may be too tired to understand, but your exact issue is, that a docker container "nextcloud" cannot connect to a docker container "eturnal"?

Sorry you're tired :(
My problem is I can't get the TURN to both connect inside nextcloud's web-client talk settings (ie the green check) and allow calls outside of the home network.
nextcloud-aio-mastercontainer generates multiple other containers as well, like nextcloud-aio-talk which I think manages the backend and its own STUN/TURN (that I couldn't get to connect internally either) I think I've shown the keys ones connecting to the domain manually below:

$ docker exec -it nextcloud-aio-talk sh
/ $ ping nextcloud.wallaby-gopher.ts.net
PING nextcloud.wallaby-gopher.ts.net (100.96.243.61): 56 data bytes
64 bytes from 100.96.243.61: seq=0 ttl=42 time=0.223 ms
--- nextcloud.wallaby-gopher.ts.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.223/0.234/0.245 ms
/ $ exit
$ docker exec -it eturnal sh
$ curl -v  https://nextcloud.wallaby-gopher.ts.net
[lengthy snip]
* Connection #0 to host nextcloud.wallaby-gopher.ts.net left intact
$ docker exec -it nextcloud-aio-apache sh
/usr/local/apache2 $ ping nextcloud.wallaby-gopher.ts.net
PING nextcloud.wallaby-gopher.ts.net (100.96.243.61): 56 data bytes
64 bytes from 100.96.243.61: seq=0 ttl=42 time=0.218 ms
--- nextcloud.wallaby-gopher.ts.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.218/0.273/0.329 ms
/ $ exit
$ docker exec -it caddy sh
/srv # ping nextcloud.wallaby-gopher.ts.net
PING nextcloud.wallaby-gopher.ts.net (100.96.243.61): 56 data bytes
64 bytes from 100.96.243.61: seq=0 ttl=63 time=0.170 ms
--- nextcloud.wallaby-gopher.ts.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.170/0.243/0.316 ms

like what @wwe was saying over on the nextcloud forum it's best to do TURN without any extra nonsense, and I haven't had any success with that (I think I just don't know what I'm supposed to do without Tailscale holding my hand). I'm wondering if I correctly setup Caddy to handle websockets as that's suggested at the troubleshooting guide here @wwe never elaborated on how to check.

One of them running in host network, the other not?

I'd prefer to remain off host mode if at possible, but I've only been able to get TURN to connect inside nextcloud when its tailscale container alone is on host mode.

Are both running on the same host?

Every container is on the same host machine, yes.

do they share the same docker network?

I connect backend things with a network, nextcloud generates its own network, and I have a third network for front facing containers. I tried adding all of them, and also tried instead of host mode adding tailscale to an extra host "host.docker.internal:host-gateway" with all of those networks.

[sando38]

Thanks for the explanation about tailscale, understood.

I believe the issue is, that the nextcloud talk tries to connect eturnal not through the docker network but through the primary networking device of your host going through your internal IP address 100.96.243.61 which I believe is not the container's IP address? can you try to ping the eturnal container with the container's IP address or container hostname? That would explain/verify why host mode works, but non-host mode not.

P.S. And did you open the 3478/udp or which ever port you use in docker compose? you need this to actually allow external connections when not using host network.

    ### networking options
    ports:
      - 3480:3480  
      - 3480:3480/udp

[wallaby-gopher]

I believe the issue is, that the nextcloud talk tries to connect eturnal not through the docker network but through the primary networking device of your host going through your internal IP address 100.96.243.61 which I believe is not the container's IP address? can you try to ping the eturnal container with the container's IP address or container hostname? That would explain/verify why host mode works, but non-host mode not.

They can definitely reach each other!

$ docker exec -it nextcloud-aio-talk sh
/ $ ping eturnal
PING eturnal (172.19.0.15): 56 data bytes
64 bytes from 172.19.0.15: seq=0 ttl=42 time=0.028 ms
64 bytes from 172.19.0.15: seq=1 ttl=42 time=0.030 ms
^C
--- eturnal ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.028/0.029/0.030 ms
/ $ 

that said, when I try to test inside nextcloud I noticed tailscale spits out this error:

2025/07/23 15:31:26 netstack: could not connect to local backend server at 127.0.0.1:3480: dial tcp 127.0.0.1:3480: connect: connection refused

2025/07/23 15:31:26 netstack: could not connect to local backend server at 127.0.0.1:3480: dial tcp 127.0.0.1:3480: connect: connection refused

2025/07/23 15:31:26 netstack: could not connect to local backend server at 127.0.0.1:3480: dial tcp 127.0.0.1:3480: connect: connection refused

2025/07/23 15:31:26 magicsock: disco: node [VBN/l] d:d0bc9ce5ad9d5e67 now using 172.17.0.1:41641 mtu=1360 tx=e9eb64bb6bf5

2025/07/23 15:33:32 netstack: UDP session between 127.0.0.1:44356 and 127.0.0.1:3480 timed out

2025/07/23 15:33:32 netstack: UDP session between 127.0.0.1:56839 and 127.0.0.1:3480 timed out

2025/07/23 15:33:32 netstack: UDP session between 127.0.0.1:48957 and 127.0.0.1:3480 timed out

Made me wonder if it needs a layer4 caddy config like this guide had done for itself, I'm not sure if I should upstream to eturnal or talk but I tried both without success

127.0.0.1:3480 {
                route {
                    proxy {
                        upstream nextcloud-aio-talk:3480
                    }
                }
            }

P.S. And did you open the 3478/udp or which ever port you use in docker compose? you need this to actually allow external connections when not using host network.

### networking options
ports:
  - 3480:3480  
  - 3480:3480/udp

I don't get to define the talk ports myself but here in an inspect it defines them

"NetworkSettings": {
            "Bridge": "",
            "SandboxID": "5b2c185d8221467c9648fbc5d33701d88ffb9ccd4f108f501cf7c25ac3c6ea7b",
            "SandboxKey": "/var/run/docker/netns/5b2c185d8221",
            "Ports": {
                "3478/tcp": [
                    {
                        "HostIp": "127.0.0.1",
                        "HostPort": "3478"
                    }
                ],
                "3478/udp": [
                    {
                        "HostIp": "127.0.0.1",
                        "HostPort": "3478"
                    }
                ]
            },

[sando38]

I believe: upstream nextcloud-aio-talk:3480 should be upstream nextcloud-aio-talk:3478 and/or upstream eturnal:3480. But looking into the inspect I only see 3478, not 3480, therefore, I believe there is port really exposed on your tailscale for eturnal's 3480.