Question: Why stunner gives the POD_IP as the RELAY candidate? about stunner

[imcom]

kubectl describe cm stunner-config
Name:         stunner-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
STUNNER_DURATION:
----
86400
STUNNER_LOGLEVEL:
----
all:INFO
STUNNER_MAX_PORT:
----
20000
STUNNER_MIN_PORT:
----
10000
STUNNER_PASSWORD:
----
abcd
STUNNER_SHARED_SECRET:
----
my-shared-secret
STUNNER_AUTH_TYPE:
----
plaintext
STUNNER_PORT:
----
3478
STUNNER_PUBLIC_ADDR:
----
172.16.8.24
STUNNER_PUBLIC_PORT:
----
30478
STUNNER_REALM:
----
abcd.abcd
STUNNER_USERNAME:
----
abcd

BinaryData
====

Events:  <none>

here is my configMap

[imcom]

kubectl describe svc stunner
Name:                     stunner
Namespace:                default
Labels:                   app=stunner
Annotations:              field.cattle.io/publicEndpoints:
                            [{"addresses":["172.16.8.24"],"port":30478,"protocol":"UDP","serviceName":"default:stunner","allNodes":true}]
Selector:                 app=stunner
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.43.194.42
IPs:                      10.43.194.42
Port:                     stunner-udp  3478/UDP
TargetPort:               3478/UDP
NodePort:                 stunner-udp  30478/UDP
Endpoints:                10.42.4.87:3478
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

[VidarHUN]

Hi imcom,

First of all if you install stunner with helm the deployment will fallback to nodeport if there is no load balancer in your cluster. So, basically you just have to deploy it with helm.

For the publicly visible POD_IP there is a small description in the [security doc].(https://github.com/l7mp/stunner/blob/main/doc/SECURITY.md)

[imcom]

Hi @VidarHUN sorry for the late reply, but I still did not get it to work. I installed Metallb in my cluster so I have LoadBalancer service now.

Here is my setup, it looks OK from my perspective

NAME                           READY   STATUS    RESTARTS   AGE
pod/stunner-664f79d558-q9dp7   2/2     Running   0          14m

NAME              TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
service/stunner   LoadBalancer   10.43.67.42   172.16.8.21   3478:30729/UDP   12m

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/stunner   1/1     1            1           14m

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/stunner-664f79d558   1         1         1       14m

172.16.8.21 is the "public IP" I could use for TURN relay. However I am still getting this POD IP from stunner. What could be the cause? Am I doing something weirdly wrong here ?

{"level":"info","ts":1660359351.5038614,"logger":"trickleCmd","caller":"cmd/trickle.go:45","msg":"Created a new PeerConnection for candidates gathering"}
{"level":"info","ts":1660359351.5075831,"logger":"trickleCmd","caller":"cmd/trickle.go:55","msg":"ICECandidate: udp4 relay 10.42.4.98:46833 related 0.0.0.0:45877"}

Thanks in advance

[imcom]

Oh, I get it, the relay candidate indeed should be the POD IP. Sorry for the confusion. Once I have a LoadBalancer in place, this is working smoothly!